All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Igor Pylypiv <ipylypiv@google.com>,
	Damien Le Moal <dlemoal@kernel.org>, Tejun Heo <tj@kernel.org>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	Akshat Jain <akshatzen@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v3 1/6] ata: libata-scsi: Fix offsets for the fixed format sense data
Date: Fri, 28 Jun 2024 17:49:22 +0200	[thread overview]
Message-ID: <Zn7bghgsMR062xbb@ryzen.lan> (raw)
In-Reply-To: <0fbf1756-5b97-44fc-9802-d481190d2bd8@suse.de>

On Fri, Jun 28, 2024 at 08:47:03AM +0200, Hannes Reinecke wrote:
> On 6/27/24 14:08, Niklas Cassel wrote:
> > Hello Igor, Hannes,
> > 
> > The changes in this patch looks good, however, there is still one thing that
> > bothers me:
> > https://github.com/torvalds/linux/blob/v6.10-rc5/drivers/ata/libata-scsi.c#L873-L877
> > 
> > Specifically the code in the else statement below:
> > 
> > 	if (qc->err_mask ||
> > 	    tf->status & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ)) {
> > 		ata_to_sense_error(qc->ap->print_id, tf->status, tf->error,
> > 				   &sense_key, &asc, &ascq);
> > 		ata_scsi_set_sense(qc->dev, cmd, sense_key, asc, ascq);
> > 	} else {
> > 		/*
> > 		 * ATA PASS-THROUGH INFORMATION AVAILABLE
> > 		 * Always in descriptor format sense.
> > 		 */
> > 		scsi_build_sense(cmd, 1, RECOVERED_ERROR, 0, 0x1D);
> > 	}
> > 
> > Looking at sat6r01, I see that this is table:
> > Table 217 — ATA command results
> > 
> > And this text:
> > No error, successful completion or command in progress. The SATL
> > shall terminate the command with CHECK CONDITION status with
> > the sense key set to RECOVERED ERROR with the additional
> > sense code set to ATA PASS-THROUGH INFORMATION
> > AVAILABLE (see SPC-5). Descriptor format sense data shall include
> > the ATA Status Return sense data descriptor (see 12.2.2.7).
> > 
> > However, I don't see anything in this text that says that the
> > sense key should always be in descriptor format sense.
> > 
> > In fact, what will happen if the user has not set the D_SENSE bit
> > (libata will default not set it), is that:
> > 
> > The else statement above will be executed, filling in sense key in
> > descriptor format, after this if/else, we will continue checking
> > if the sense buffer is in descriptor format, or fixed format.
> > 
> > Since the scsi_build_sense(cmd, 1, RECOVERED_ERROR, 0, 0x1D);
> > is called with (..., 1, ..., ..., ...) it will always generate
> > the sense data in descriptor format, regardless of
> > dev->flags ATA_DFLAG_D_SENSE being set or not.
> > 
> > Should perhaps the code in the else statement be:
> > 
> > } else {
> > 	ata_scsi_set_sense(qc->dev, cmd, RECOVERED_ERROR, 0, 0x1D);
> > }
> > 
> > So that we actually respect the D_SENSE bit?
> > 
> > (We currently respect if when filling the sense data buffer with
> > sense data from REQUEST SENSE EXT, so I'm not sure why we shouldn't
> > respect it for successful ATA PASS-THROUGH commands.)
> > 
> I guess that we've misread the spec.

I think I might have an idea where you got this from:

In sat5r06.pdf
"""
12.2.2.8 Fixed format sense data

Table 212 shows the fields returned in the fixed format sense data (see SPC-5) for ATA PASS-THROUGH
commands. SATLs compliant with ANSI INCITS 431-2007, SCSI/ATA Translation (SAT) return descriptor
format sense data for the ATA PASS-THROUGH commands regardless of the setting of the D_SENSE bit.
"""

In sat6r01.pdf:
"""
12.2.2.8 Fixed format sense data

Table 219 shows the fields returned in the fixed format sense data (see SPC-5)
for ATA PASS-THROUGH
commands.
"""

In SAT-6 there is no mention of compliance with ANSI INCITS 431-2007 should
ignore D_SENSE bit and unconditionally return sense data in descriptor format.

Anyway, considering that:
1) I'm not sure how a SAT would expose that it is compliant with ANSI INCITS
   431-2007.
2) This text has been removed from SAT-6.
3) We currently honour the D_SENSE bit when creating the sense buffer with the
   SK/ASC/ASCQ that we get from the device.

I think that it makes sense to honour the D_SENSE bit also when generating
sense data for successful ATA PASS-THROUGH commands (from ATA registers).


Kind regards,
Niklas

  reply	other threads:[~2024-06-28 15:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-26 23:04 [PATCH v3 0/6] ATA PASS-THROUGH sense data fixes Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 1/6] ata: libata-scsi: Fix offsets for the fixed format sense data Igor Pylypiv
2024-06-27 12:08   ` Niklas Cassel
2024-06-27 21:21     ` Igor Pylypiv
2024-06-28  6:47     ` Hannes Reinecke
2024-06-28 15:49       ` Niklas Cassel [this message]
2024-06-28 18:25         ` Niklas Cassel
2024-06-28 23:17           ` Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 2/6] ata: libata-scsi: Do not overwrite valid sense data when CK_COND=1 Igor Pylypiv
2024-06-27  0:16   ` Damien Le Moal
2024-06-27 20:55     ` Igor Pylypiv
2024-06-28  3:48       ` Damien Le Moal
2024-06-27 14:14   ` Niklas Cassel
2024-06-27 15:15     ` Niklas Cassel
2024-06-27 21:54     ` Igor Pylypiv
2024-06-28 18:44       ` Niklas Cassel
2024-06-28 23:31         ` Igor Pylypiv
2024-06-29  3:09           ` Niklas Cassel
2024-07-01 20:00             ` Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 3/6] ata: libata-scsi: Remove redundant sense_buffer memsets Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 4/6] ata: libata-scsi: Do not pass ATA device id to ata_to_sense_error() Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 5/6] ata: libata: Set ATA_QCFLAG_RTF_FILLED in fill_result_tf() Igor Pylypiv
2024-06-28 20:12   ` Niklas Cassel
2024-06-28 23:08     ` Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 6/6] ata: libata-scsi: Check ATA_QCFLAG_RTF_FILLED before using result_tf Igor Pylypiv
2024-06-27  0:19   ` Damien Le Moal
2024-06-27 22:03     ` Igor Pylypiv
2024-06-27  6:16   ` Hannes Reinecke
2024-06-28 19:42   ` Niklas Cassel
2024-06-28 23:15     ` Igor Pylypiv

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zn7bghgsMR062xbb@ryzen.lan \
    --to=cassel@kernel.org \
    --cc=akshatzen@google.com \
    --cc=dlemoal@kernel.org \
    --cc=hare@suse.de \
    --cc=ipylypiv@google.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.