From owner-freebsd-scsi@freebsd.org Wed Mar 2 16:15:42 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1F82AC13D1 for ; Wed, 2 Mar 2016 16:15:42 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm7-vm4.bullet.mail.gq1.yahoo.com (nm7-vm4.bullet.mail.gq1.yahoo.com [98.136.218.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F7D71C7E for ; Wed, 2 Mar 2016 16:15:42 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456935148; bh=+heFZYjM/DlmXP2giZ8PsKIBw5ITWqNZwBdQ2xzFlYY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=Uway9YV57XHiS5O2Bkbox10XRcJfEgkoeD0xeNq4cOblgJHtem75mDJcJ2cYzhniB/L6dddrJ6dSdM1pMnm1umG90oXkD2L5DpOFkUNxE4NrtfTylNbyNB37l5gIfl/TQFdILh3O30J9TGnMQijhPPjLXRbIrsZOGy2Exl36BhUCgUJOcJDgV91BJ9DLzPU72BTUswPyPhZ5xjwQQFBTtvVxpFzx4xN+CDE3SeUAGe4hO4eDqX/OvgsIXULIQPqhsla/xJg2maDbfTHjaK/ozDqGbAf4M4fR1oZWTYn0xMM0FQED3V3MYzmlqdrn2s6eUVZp5X84OZ4iPqZJVtgPWQ== Received: from [216.39.60.180] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 02 Mar 2016 16:12:28 -0000 Received: from [208.71.42.199] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 02 Mar 2016 16:12:28 -0000 Received: from [127.0.0.1] by smtp210.mail.gq1.yahoo.com with NNFMP; 02 Mar 2016 16:12:28 -0000 X-Yahoo-Newman-Id: 148981.87868.bm@smtp210.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SwtqhlwVM1mK8KeL9g5sB39KARXzkz7mz5W0ZagByQwPBUu 7cTEEy9cW5pzZMcaoLzfs4UO8pn4I5GDpH9xCpKw8L63VcqObo0ySGlX0_5t Xr34jkliOXNu_UQBsq4WBOYnuUVCH0iTStWivt.1ijvjMzjbhc3V0NIZ7ZBY VOw5Fbdoci8nbYPY2R1drNiLG0JUZOpQbOf28s.afuKu5FxknoakyNd3nTQG FNY8KdpCXe4xmQVU3IESfeLP1HUHR3ehTdsPDq92A0KsIkIGS3C8t31vSmUK 2dbSQ.V2byHcXo3VRl2JIcT4jHPjXecfZJYQZTncMlRG6bpVDbk9NyG6fGEY 4PSJo87CeKFvoCFAnLW7qgSQoHcUYsaRcvOVLeIkijSNSf0AH7.Ee65JEkmK I0BFy65sDoXFnJrMjUkIWM_uR8yFx8gGH_9XCtORGoz_f1HF.VcRsg7vvcUg rdNIb6Rpp4blR4t3vvayQHRLzoJOm2nK.5TOdPepFBFVZJIBfVEEWxFJaQBl 2uid5pC2gOecAZeG.nw_o_usyZ8YPxYdHUkeEP3PRW14NoA-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: CAM Shingled Disk support patches available From: Scott Long In-Reply-To: <56D6BAA7.1050004@multiplay.co.uk> Date: Wed, 2 Mar 2016 09:12:25 -0700 Cc: freebsd-scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160301224758.GA86834@mithlond.kdm.org> <56D6BAA7.1050004@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:15:42 -0000 > On Mar 2, 2016, at 3:04 AM, Steven Hartland = wrote: >=20 > scsi_ata_pass_16 was added to support TRIM and implements 12.2.3 (not = 12.2.2) providing access to all features as described by Table 104. I'll = admit I didn't take into account callers which make non LBA use of the = LBA fields, but I'm sure you'll agree that's an experience thing i.e. = knowing about about the existence of features which abuse structure = fields for other purposes ;-) >=20 I=E2=80=99m going from SAT-3r5, which unfortunately is the only rev I = have since T10 makes it hard to get SAT-3r7. Maybe the numbers changed? = I meant 12.2.2.x, which covers 12.2.2.1, 12.2.2.2, and 12.2.2.3 in the = draft that I have. There is no 12.2.3 in my draft. > Its use of u_int16_t dxfer_len is a bug, surprised the compiler didn't = flag this, not sure this can be fixed without breaking backwards = compatibility though? >=20 > Not sure I understand the 12 vs 13 registers comment, I'm guessing you = mean the 12 bytes of 12.2.2, however it actually exposes all 16 bytes of = 12.2.3. >=20 scsi_ata_pass_16 doesn=E2=80=99t accept a device argument and assumes it = to be ATA_DEV_LBA, 0x40. There are two commands in ACS-3, = READ_FPDMA_QUEUED and WRITE_FPDMA_QUEUED, that could use a different = value for bit 7. Maybe that=E2=80=99s an unlikely case for userland = passthrough, but not impossible. However bit 4 is also a wildcard that = is transport-dependent for many commands. SATA is pretty clear about = the bit always being zero. Technically in PATA you might want to = control bit 4 to specify the master vs slave device, but I=E2=80=99m = guessing that FreeBSD would be more likely to override that than support = it. Still, I haven=E2=80=99t done a comprehensive review of all command = sets and transports, and I think it would be prudent to leave the device = register exposed to the API rather than hard-coded. > For reference it has two callers in the kernel scsi_ata_identify used = to probe TRIM capability and scsi_ata_trim used to actually perform TRIM = operations. >=20 > In addition to this its also used by camcontrol to support passthrough = from ata_do_cmd and ata_do_28bit_cmd again supporting TRIM, in this case = the ATA security feature set as well as identify. >=20 > I would be very surprised if its used elsewhere but in order to = maintain compatibility I'd definitely agree with Scott on creating an = scsi_ata_pass which can be used to implement and scsi_ata_pass_16 which = can then be deprecated. >=20 It=E2=80=99s exposed in libcam.so, and it sounds like Ken is also = expanding its use, so it=E2=80=99s fair to say that it might have a = wider audience than just those TRIM uses. > With regards to providing 12.2.2 and 12.2.3 by looking at AP_EXTEND I = don't believe that's possible as you need this to tell the difference = between 28bit and 48bit ATA within 12.2.3. >=20 12.2.2.3 states the following: If the EXTEND bit is set to zero, then the FEATURES (15:8) field, the = SECTOR_COUNT (15:8) field, the LBA_LOW (15:8) field, then the LBA_MID = (15:8) field, and the LBA_HIGH (15:8) field shall be ignored by the = SATL, and the SATL shall process this command as specified in 12.2.2.2. My proposal isn=E2=80=99t completely correct, it would be abusing the = EXTEND bit to force the use of opcode A1 vs 85, and really the spec says = that 85 can be used with the bit being zero. One might want to send an = 0x85 opcode with EXTEND set to zero to test that the receiver will do = the right thing with ignoring the 5 extended fields, or you might have a = receiver that only accepts 0x85 but you need to send a 28 bit command. = So yeah, I concede it=E2=80=99s not great. Might need to either add an = extra flag, or split the function into two. Scott