From: Marc C <marc.ceeeee@gmail.com>
To: linux-ide@vger.kernel.org
Subject: Re: [PATCH v3 1/3] libata: Populate host-to-device FIS "auxiliary" field
Date: Fri, 09 Aug 2013 19:06:35 -0700 [thread overview]
Message-ID: <5205A02B.6010208@gmail.com> (raw)
In-Reply-To: <52059FBF.7050303@gmail.com>
Hello,
> The auxiliary field is part of ata taskfile for all intents and purposes.
> FIS is the new command structure anyway and struct ata_taskfile proper
> should be able to describe the command with ata_queuedcmd providing
> the surrounding context. The argument that ata_taskfile shouldn't
> contain anything which wasn't in PATA taskfile is bogus as it already
> contains ATA_TFLAG_*.
> That's what make 'struct ata_taskfile' bogus. I'm going to remove
> 'protocol', 'flags', and 'ctl' fields from there (at least to save a space in
> 'struct ata_queued_cmd' because they're not used in 'result_tf').
>
>> So, please put the aux field into ata_taskfile. That's where it
>> belongs.
> Can't agree to that. I was going to make 'struct ata_taskfile' reflect the
> historical notion and remove from it all not belonging to that notion. Alas,
> libata has a bad history of mistreating the historical terms...
While I understand that some non-spec items don't belong in the taskfile struct (and should/will be cleaned up), I have to agree with Tejun regarding how the auxiliary field should be put in 'struct ata_taskfile'. If anything, the struct should represent ALL items that an ATA command will use as inputs. As of now, it's the stuff that's currently in the taskfile + this pesky new 'auxiliary' entry. (FYI, ATA-8 ACS refers to these items as"fields.")
>From what I can tell, there are a couple of places where a rigid definition of a taskfile truly matters, and that's:
1) SCSI to ATA passthrough
2) PATA
But in any event, sticking 'auxiliary' in doesn't matter from a compatibility standpoint, since only NCQ commands use the new field, and the above can't transport NCQ (yet in (1) case).
Tejun put it succinctly by stating:
> I mean, FIS is the new TF. We can rename ata_taskfile to
> ata_fis and map things the other way but that'd just be extra churn.
Ideally this would be the case, since the SATA FIS is a super-set of any/all fields defined in all ATA commands.
Regards,
Marc
next parent reply other threads:[~2013-08-10 2:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52059FBF.7050303@gmail.com>
2013-08-10 2:06 ` Marc C [this message]
2013-08-09 4:49 [PATCH v3 0/3] Introduce new SATA queued commands Marc C
2013-08-09 4:49 ` [PATCH v3 1/3] libata: Populate host-to-device FIS "auxiliary" field Marc C
2013-08-09 14:03 ` Tejun Heo
2013-08-09 14:36 ` Sergei Shtylyov
2013-08-09 14:53 ` Tejun Heo
2013-08-09 21:39 ` Sergei Shtylyov
2013-08-09 21:51 ` Tejun Heo
2013-08-09 22:17 ` Sergei Shtylyov
2013-08-09 22:26 ` Tejun Heo
2013-08-10 21:59 ` Sergei Shtylyov
2013-08-12 13:58 ` Tejun Heo
2013-08-09 21:24 ` Sergei Shtylyov
2013-08-09 14:17 ` Sergei Shtylyov
2013-08-09 14:29 ` Sergei Shtylyov
2013-08-09 14:26 ` Sergei Shtylyov
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=5205A02B.6010208@gmail.com \
--to=marc.ceeeee@gmail.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;
as well as URLs for NNTP newsgroup(s).