public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Igor Pylypiv <ipylypiv@google.com>
Cc: Damien Le Moal <dlemoal@kernel.org>, linux-ide@vger.kernel.org
Subject: Re: [PATCH v2] ata: libata-sata: Use LBA from sense data descriptor
Date: Thu, 10 Apr 2025 15:02:33 +0200	[thread overview]
Message-ID: <Z_fBaVZkcD9AtTaR@ryzen> (raw)
In-Reply-To: <Z_aul100eqb2-naM@google.com>

On Wed, Apr 09, 2025 at 10:29:59AM -0700, Igor Pylypiv wrote:
> On Wed, Apr 09, 2025 at 10:45:47AM +0200, Niklas Cassel wrote:
> > The definition of the LBA field in the sense data descriptor is:
> > 
> > "If definition of the sense data to be returned when a command completes
> > without an error includes an LBA value, then the LBA field contains the
> > defined value. Otherwise, the LBA field contains a copy of the LBA field
> > in the command inputs for the command that completed without an error
> > and returned sense data."
> > 
> > Thus, the LBA field in the sense data descriptor can contain a LBA value
> > that is different from the LBA field in the command input.
> > 
> > Therefore, just like how ata_eh_read_log_10h() overrides qc->result_tf
> > with the LBA in the NCQ Command Error log, override qc->result_tf with
> > the LBA in the Successful NCQ Commands log.
> 
> Hi Niklas,
> 
> Should we also override other fields e.g. COMMAND, FEATURE, COUNT, AUXILIARY?
> I understand that per current SAT spec those fields contain data from command
> inputs so we can get the same data directly from qc->tf and technically don't
> need to fill qc->result_tf with the same.
> 
> If I understand correctly, qc->result_tf contains data filled from a shared
> FIS so it is likely that it contains data that belongs to some other command,
> is that true? If that's true, should we clear the qc->result_tf before filling
> the fields with data from the Successful NCQ Commands log?

For AHCI, for a successful NCQ command, we will fill the result TF from the
SDB FIS in the FIS Receive Area, and will set ATA_QCFLAG_RTF_FILLED:
https://github.com/torvalds/linux/blob/v6.15-rc1/drivers/ata/libahci.c#L2153-L2158

The FIS Receive Area will get overwritten with each new received SDB FIS,
as it can only hold one SDB FIS.
(For libsas drivers, usually each completion can access the exact FIS that
completed the IO.)


A CDL command will set ATA_QCFLAG_RESULT_TF, but since ATA_QCFLAG_RTF_FILLED
is already set, fill_result_tf() will be a no-op.

If it was an NCQ error, ata_eh_read_log_10h() will set/overwrite qc->result_tf
with the information from the NCQ Command Error log, but for an NCQ error
there can be only one tag that caused the error:
https://github.com/torvalds/linux/blob/v6.15-rc1/drivers/ata/libata-sata.c#L1472-L1482

Both for a failed and a successful command qc->result_tf should be cleared
for a new QC, so I don't think we need to clear anything.
(And as you saw, ahci_qc_ncq_fill_rtf() only fills status, error, and flags.)


I chose to only fill LBA from the sense data descriptor, because, as you
said, "9.29.3 Successful Sense Data descriptor" says that:
COMMAND field, FEATURE field, and COUNT field are copies of the input command.

Sure, ata_eh_read_log_10h() does fill in all these fields, so strictly
speaking, we probably should fill qc->result_tf with COMMAND, FEATURE,
and COUNT, even if they will always have the same values as qc->tf...

But... even for a NCQ QC with ATA_QCFLAG_RESULT_TF, we have so far only
been filling STATUS, ERROR and flags, basically because that is the only
information that is available in the Set Device Bits (SDB) FIS that is
received on NCQ completion (and no one has complained yet...)

I guess now when we do have access to the information, the most consistent
thing would be to fill all field we can in qc->result_tf... but, to do this
for every IO might slow things down.

So is there perhaps some logic to only filling LBA (in addition to STATUS
and ERROR, which are filled for all NCQ commands), since that is the only
field that can change, as per the specs.

Damien, thoughts?


Kind regards,
Niklas

  reply	other threads:[~2025-04-10 13:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09  8:45 [PATCH v2] ata: libata-sata: Use LBA from sense data descriptor Niklas Cassel
2025-04-09 17:29 ` Igor Pylypiv
2025-04-10 13:02   ` Niklas Cassel [this message]
2025-04-10 14:04     ` Niklas Cassel
2025-04-10 17:00       ` Igor Pylypiv
2025-04-11  6:35         ` Niklas Cassel
2025-04-11  0:01       ` Damien Le Moal

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=Z_fBaVZkcD9AtTaR@ryzen \
    --to=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=ipylypiv@google.com \
    --cc=linux-ide@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox