From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753508AbcIOUww (ORCPT ); Thu, 15 Sep 2016 16:52:52 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:51889 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751570AbcIOUwn (ORCPT ); Thu, 15 Sep 2016 16:52:43 -0400 MIME-Version: 1.0 In-Reply-To: References: From: "Jason A. Donenfeld" Date: Thu, 15 Sep 2016 22:52:34 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TRIM/UNMAP/DISCARD via ATA Passthrough To: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org, LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Martin, On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen > But how do they signal that ATA passthrough is possible? Is there an ATA > Information VPD page? Is REPORT SUPPORTED OPERATION CODES supported? > > We need really solid discovery data before we can entertain enabling > something like this. `sg_opcodes` said invalid request, so I think there isn't REPORT SUPPORTED OPERATION CODES, and `sg_vpd -p ai` came up illegal too. However, sg_sat_identify worked reliably, which means a solid way of probing this would be to send IDENTIFY DEVICE ATA via SG_ATA_16 or SG_ATA_12. Let me know and I can give you access to the hardware if you're curious. Regards, Jason