[{"id":3676241,"web_url":"http://patchwork.ozlabs.org/comment/3676241/","msgid":"<d1f74993-5f7a-4496-be7f-797652477fa6@kernel.org>","list_archive_url":null,"date":"2026-04-12T07:06:42","subject":"Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA\n PASS-THROUGH commands","submitter":{"id":86188,"url":"http://patchwork.ozlabs.org/api/people/86188/","name":"Damien Le Moal","email":"dlemoal@kernel.org"},"content":"On 4/11/26 01:15, Igor Pylypiv wrote:\n> Commit 0ea84089dbf6 (\"ata: libata-scsi: avoid Non-NCQ command starvation\")\n> introduced ata_scsi_requeue_deferred_qc() to handle commands deferred\n> during resets or NCQ failures. This deferral logic completed commands\n> with DID_SOFT_ERROR to trigger a retry in the SCSI mid-layer.\n> \n> However, DID_SOFT_ERROR is subject to scsi_cmd_retry_allowed() checks.\n> ATA PASS-THROUGH commands sent via SG_IO ioctl have scmd->allowed set\n> to zero. This causes the mid-layer to fail the command immediately\n> instead of retrying, even though the command was never actually issued\n> to the hardware.\n> \n> Switch to DID_REQUEUE to ensure these commands are inserted back into\n> the request queue regardless of retry limits.\n\nI really thought that DID_SOFT_ERROR was not decrementing the retry counter.\nChecking the code again, I was wrong. Good catch !\n\n> Fixes: 0ea84089dbf6 (\"ata: libata-scsi: avoid Non-NCQ command starvation\")\n> Signed-off-by: Igor Pylypiv <ipylypiv@google.com>\n\nReviewed-by: Damien Le Moal <dlemoal@kernel.org>","headers":{"Return-Path":"\n <linux-ide+bounces-5472-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ide@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=PqTxhxnS;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-ide+bounces-5472-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"PqTxhxnS\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fthRb0nzGz1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 17:06:50 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id E675130074C4\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 07:06:48 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 5E2112D3ED1;\n\tSun, 12 Apr 2026 07:06:46 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B3A025C6EE;\n\tSun, 12 Apr 2026 07:06:45 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id EB355C19424;\n\tSun, 12 Apr 2026 07:06:43 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775977606; cv=none;\n b=N5WBYUhpjivZmZUkWRc2x/3wluDDnASKa33kXtENZ6xtkZbN36ckEA0NUdI1FuaRYzAYj3tLfyp6tLWZYkuMDtJa70GAplBxZWU567075KLGpP+Zq8zi2VAJkeFls3Nf1Md2Gp6WimiS4lmvbRPN0hZmUDHS6mIA5L7r4oxRM14=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775977606; c=relaxed/simple;\n\tbh=piPTtxWdeHkJmiAvnn6mW8xtz1+41ziC+xy5YtOdpL8=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=XFvl6d8V96dUf7p0rA+5QvWTo5OYsdJ5ePNAn5C8vlbNYx0mp8K3QRVw2s6xhRauqbdigzZy148YwCc7uTmmCHxPbyroQ/zXTFvYJHyX66QjXBjKEm5Id7bbyEQvTGfWFyF4QiGNPhbmyqhZS2RHWj+HydspDkktOgxd2SjmMr8=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=PqTxhxnS; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775977605;\n\tbh=piPTtxWdeHkJmiAvnn6mW8xtz1+41ziC+xy5YtOdpL8=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=PqTxhxnSaQLrHAmX4m+LNNO6BhoeuPn122bz0wVco+RX+y+zzUcXVLFyQ449VVL9B\n\t 7oJ2QqzBMdfd9oPP95bN9EepLLhblIOoQDc1m9+PLS/NomFSd8ONPe3ccdJiOiN+9m\n\t zK/DNF/+9g/klmLHfyZ37tomnuXQvZ21AJ6LQABRsizoYypvAuaKBQl8rJxaOWcGaA\n\t PDPj3+ziJ3M31IDTiCOjH3HJHWkXEgae+RY2xhyuR0UEDrh8b1ukdHxvlRt+1Owinc\n\t 7GVYOqA4qFgvn7JMo5OJ/nnFEVlYb40M5UXv2VVkbvQtZ28Z1VgBWTybu/Q603ZD1a\n\t 1un+qd+2q7bdA==","Message-ID":"<d1f74993-5f7a-4496-be7f-797652477fa6@kernel.org>","Date":"Sun, 12 Apr 2026 09:06:42 +0200","Precedence":"bulk","X-Mailing-List":"linux-ide@vger.kernel.org","List-Id":"<linux-ide.vger.kernel.org>","List-Subscribe":"<mailto:linux-ide+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ide+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA\n PASS-THROUGH commands","To":"Igor Pylypiv <ipylypiv@google.com>, Niklas Cassel <cassel@kernel.org>","Cc":"\"Martin K. Petersen\" <martin.petersen@oracle.com>,\n John Garry <john.g.garry@oracle.com>, Xingui Yang <yangxingui@huawei.com>,\n linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org","References":"<20260410231519.951971-1-ipylypiv@google.com>","Content-Language":"en-US","From":"Damien Le Moal <dlemoal@kernel.org>","Organization":"Western Digital Research","In-Reply-To":"<20260410231519.951971-1-ipylypiv@google.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit"}},{"id":3676258,"web_url":"http://patchwork.ozlabs.org/comment/3676258/","msgid":"<adt3JqwFcDx-Xe30@fedora>","list_archive_url":null,"date":"2026-04-12T10:42:46","subject":"Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA\n PASS-THROUGH commands","submitter":{"id":87751,"url":"http://patchwork.ozlabs.org/api/people/87751/","name":"Niklas Cassel","email":"cassel@kernel.org"},"content":"On Fri, Apr 10, 2026 at 04:15:19PM -0700, Igor Pylypiv wrote:\n> Commit 0ea84089dbf6 (\"ata: libata-scsi: avoid Non-NCQ command starvation\")\n> introduced ata_scsi_requeue_deferred_qc() to handle commands deferred\n> during resets or NCQ failures. This deferral logic completed commands\n> with DID_SOFT_ERROR to trigger a retry in the SCSI mid-layer.\n> \n> However, DID_SOFT_ERROR is subject to scsi_cmd_retry_allowed() checks.\n> ATA PASS-THROUGH commands sent via SG_IO ioctl have scmd->allowed set\n> to zero. This causes the mid-layer to fail the command immediately\n> instead of retrying, even though the command was never actually issued\n> to the hardware.\n> \n> Switch to DID_REQUEUE to ensure these commands are inserted back into\n> the request queue regardless of retry limits.\n> \n> Fixes: 0ea84089dbf6 (\"ata: libata-scsi: avoid Non-NCQ command starvation\")\n> Signed-off-by: Igor Pylypiv <ipylypiv@google.com>\n> ---\n>  drivers/ata/libata-scsi.c | 4 ++--\n>  1 file changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c\n> index 3b65df914ebb..0236394900cc 100644\n> --- a/drivers/ata/libata-scsi.c\n> +++ b/drivers/ata/libata-scsi.c\n> @@ -1692,7 +1692,7 @@ void ata_scsi_requeue_deferred_qc(struct ata_port *ap)\n>  \t/*\n>  \t * If we have a deferred qc when a reset occurs or NCQ commands fail,\n>  \t * do not try to be smart about what to do with this deferred command\n> -\t * and simply retry it by completing it with DID_SOFT_ERROR.\n> +\t * and simply requeue it by completing it with DID_REQUEUE.\n>  \t */\n>  \tif (!qc)\n>  \t\treturn;\n> @@ -1701,7 +1701,7 @@ void ata_scsi_requeue_deferred_qc(struct ata_port *ap)\n>  \tap->deferred_qc = NULL;\n>  \tcancel_work(&ap->deferred_qc_work);\n>  \tata_qc_free(qc);\n> -\tscmd->result = (DID_SOFT_ERROR << 16);\n> +\tset_host_byte(scmd, DID_REQUEUE);\n\nset_host_byte() will set the host byte, but it will keep the status byte\nand the ML byte intact.\n\nBy using the assignment operator, I assumed that Damien intentionally\nwanted to clear the status byte and the ML byte.\n\nMy point is that using set_host_byte() is a logical change.\nIf we want to stop clearing the status byte and the ML byte, then I think\nthat change should be in a separate commit, with a proper motivation/commit\nmessage.\n\nHowever, for the fix patch itself, I think we should just do:\n-\tscmd->result = (DID_SOFT_ERROR << 16);\n+\tscmd->result = (DID_REQUEUE << 16);\n\n\nIf that is sufficient to fix your observed problem.\n\nI would also be happy to see a follow up patch that changes to use\nset_host_byte(), if there is a motivation that can motivate why that change\nis safe/valid.\n\n\nKind regards,\nNiklas","headers":{"Return-Path":"\n <linux-ide+bounces-5476-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ide@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=i0UMKbwr;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-ide+bounces-5476-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"i0UMKbwr\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4ftnF16LF1z1yCx\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 20:43:01 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 8EB2C30065FC\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 10:42:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 4C7DE2FC01B;\n\tSun, 12 Apr 2026 10:42:52 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 27FDF1D5151;\n\tSun, 12 Apr 2026 10:42:52 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 9C671C19424;\n\tSun, 12 Apr 2026 10:42:49 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775990572; cv=none;\n b=Cf3I55kh5eMgYfgNknn1aIBEFXb8my2RS+sVtopdqsljN6d8PJgG3QHgRDalGLBVOS/djaSFjBmilQDc8J6wxZbeKGM30ZvzBFsmplwj8NJkea7cpNZF92fhUK+0jEfqvy87ZVOoc/cf8VC5q8yCT1DUfzeWjYp817Q+7EHS33k=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775990572; c=relaxed/simple;\n\tbh=AZbOoikGmncQ+1zfs/8uAtJ8jAVI+LGDVPzQ/NHMwkc=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Vsr3XK+HKWuXSrhiucGtXB4GhqBbQp8Hl+JWH5MZTmaDCabLGTJb32eMlRqzDRZLEm/I/yZFwR8uv/TeOZouCcmJj0mFYh1fK9YO9YmNQwG7qE41Y1n6WlhiCfd37VNH+IAt6MoDQBXTdCsEJOWkmpdOI9l4X0J+RwWn5MLLWyI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=i0UMKbwr; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775990571;\n\tbh=AZbOoikGmncQ+1zfs/8uAtJ8jAVI+LGDVPzQ/NHMwkc=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=i0UMKbwrNw3CAFkVCW/x7t5fW5uYj/26cZm1KFdqratQd9nDi+CFR0SCGP5hFhZVn\n\t QEiAUH/KiuScAorTTgsMUeC4FiISzFUePjTt7EQ7eXS1iHLiSeErWAzuc1kQjowREf\n\t M/V4NWDzAFRkmscRIOKZI+J8BwZajO8bHArrb1GogahNESTNj9FR1j0s8Yc79NnzFW\n\t ojX6Hp5eTOIvRBfv49Oq2rQjsuxaPQcjzh29ITYSmQ5ddTzmFc2GbAKGIJRRYl1shz\n\t ihE+1sB6gny20OzfUG5qFEDvKlX6rfvcymRrNYFUN6raTr6Gx1C1liTW8qHQegPt6z\n\t KNuiB3CNyVIsw==","Date":"Sun, 12 Apr 2026 12:42:46 +0200","From":"Niklas Cassel <cassel@kernel.org>","To":"Igor Pylypiv <ipylypiv@google.com>","Cc":"Damien Le Moal <dlemoal@kernel.org>,\n\t\"Martin K. Petersen\" <martin.petersen@oracle.com>,\n\tJohn Garry <john.g.garry@oracle.com>,\n\tXingui Yang <yangxingui@huawei.com>, linux-ide@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","Subject":"Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA\n PASS-THROUGH commands","Message-ID":"<adt3JqwFcDx-Xe30@fedora>","References":"<20260410231519.951971-1-ipylypiv@google.com>","Precedence":"bulk","X-Mailing-List":"linux-ide@vger.kernel.org","List-Id":"<linux-ide.vger.kernel.org>","List-Subscribe":"<mailto:linux-ide+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ide+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260410231519.951971-1-ipylypiv@google.com>"}},{"id":3676306,"web_url":"http://patchwork.ozlabs.org/comment/3676306/","msgid":"<adu5N3dSydy1uGXM@google.com>","list_archive_url":null,"date":"2026-04-12T15:24:39","subject":"Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA\n PASS-THROUGH commands","submitter":{"id":86149,"url":"http://patchwork.ozlabs.org/api/people/86149/","name":"Igor Pylypiv","email":"ipylypiv@google.com"},"content":"On Sun, Apr 12, 2026 at 12:42:46PM +0200, Niklas Cassel wrote:\n> On Fri, Apr 10, 2026 at 04:15:19PM -0700, Igor Pylypiv wrote:\n> > Commit 0ea84089dbf6 (\"ata: libata-scsi: avoid Non-NCQ command starvation\")\n> > introduced ata_scsi_requeue_deferred_qc() to handle commands deferred\n> > during resets or NCQ failures. This deferral logic completed commands\n> > with DID_SOFT_ERROR to trigger a retry in the SCSI mid-layer.\n> > \n> > However, DID_SOFT_ERROR is subject to scsi_cmd_retry_allowed() checks.\n> > ATA PASS-THROUGH commands sent via SG_IO ioctl have scmd->allowed set\n> > to zero. This causes the mid-layer to fail the command immediately\n> > instead of retrying, even though the command was never actually issued\n> > to the hardware.\n> > \n> > Switch to DID_REQUEUE to ensure these commands are inserted back into\n> > the request queue regardless of retry limits.\n> > \n> > Fixes: 0ea84089dbf6 (\"ata: libata-scsi: avoid Non-NCQ command starvation\")\n> > Signed-off-by: Igor Pylypiv <ipylypiv@google.com>\n> > ---\n> >  drivers/ata/libata-scsi.c | 4 ++--\n> >  1 file changed, 2 insertions(+), 2 deletions(-)\n> > \n> > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c\n> > index 3b65df914ebb..0236394900cc 100644\n> > --- a/drivers/ata/libata-scsi.c\n> > +++ b/drivers/ata/libata-scsi.c\n> > @@ -1692,7 +1692,7 @@ void ata_scsi_requeue_deferred_qc(struct ata_port *ap)\n> >  \t/*\n> >  \t * If we have a deferred qc when a reset occurs or NCQ commands fail,\n> >  \t * do not try to be smart about what to do with this deferred command\n> > -\t * and simply retry it by completing it with DID_SOFT_ERROR.\n> > +\t * and simply requeue it by completing it with DID_REQUEUE.\n> >  \t */\n> >  \tif (!qc)\n> >  \t\treturn;\n> > @@ -1701,7 +1701,7 @@ void ata_scsi_requeue_deferred_qc(struct ata_port *ap)\n> >  \tap->deferred_qc = NULL;\n> >  \tcancel_work(&ap->deferred_qc_work);\n> >  \tata_qc_free(qc);\n> > -\tscmd->result = (DID_SOFT_ERROR << 16);\n> > +\tset_host_byte(scmd, DID_REQUEUE);\n> \n> set_host_byte() will set the host byte, but it will keep the status byte\n> and the ML byte intact.\n> \n> By using the assignment operator, I assumed that Damien intentionally\n> wanted to clear the status byte and the ML byte.\n> \n> My point is that using set_host_byte() is a logical change.\n> If we want to stop clearing the status byte and the ML byte, then I think\n> that change should be in a separate commit, with a proper motivation/commit\n> message.\n> \n> However, for the fix patch itself, I think we should just do:\n> -\tscmd->result = (DID_SOFT_ERROR << 16);\n> +\tscmd->result = (DID_REQUEUE << 16);\n> \n\nHi Niklas,\n\nThank you for pointing it out. I agree. Switching to set_host_byte()\nis logically a different change from the problem that this commit\nis fixing. There is no particular need for using set_host_byte().\n\nI'll send a v2 to drop set_host_byte().\n\nThanks,\nIgor\n\n> \n> If that is sufficient to fix your observed problem.\n> \n> I would also be happy to see a follow up patch that changes to use\n> set_host_byte(), if there is a motivation that can motivate why that change\n> is safe/valid.\n> \n> \n> Kind regards,\n> Niklas","headers":{"Return-Path":"\n <linux-ide+bounces-5477-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ide@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256\n header.s=20251104 header.b=kRjBf64B;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-ide+bounces-5477-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=google.com header.i=@google.com\n header.b=\"kRjBf64B\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=74.125.82.53","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=google.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=google.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4ftvZp4Gpmz1yCx\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 01:28:49 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 08964306E5BD\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 12 Apr 2026 15:24:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 71D8A37DEA0;\n\tSun, 12 Apr 2026 15:24:49 +0000 (UTC)","from mail-dl1-f53.google.com (mail-dl1-f53.google.com\n [74.125.82.53])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AF2C382F16\n\tfor <linux-ide@vger.kernel.org>; Sun, 12 Apr 2026 15:24:45 +0000 (UTC)","by mail-dl1-f53.google.com with SMTP id\n a92af1059eb24-1270f10a774so28218c88.1\n        for <linux-ide@vger.kernel.org>; Sun, 12 Apr 2026 08:24:45 -0700 (PDT)","from google.com (91.195.168.34.bc.googleusercontent.com.\n [34.168.195.91])\n        by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2d55faa571csm15163191eec.10.2026.04.12.08.24.43\n        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n        Sun, 12 Apr 2026 08:24:44 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776007489; cv=none;\n b=ltHdJ2YJJPvqp5Fn6f2IUpo1+PSJHhpOj+AfJtxTenEX6UZWwCqnHyORwokUHyq3WK7cZh2+rFIAinSIvNzY+UeqT/lyZ++Dh3iJU9wjfv4+TV8KF1+Scch0dHA4hiXpt6oKVd9KxC5GW5SXnjjcRSgvOvlATl4ti7j19MY+nyE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776007489; c=relaxed/simple;\n\tbh=XgP3KwC58zb3/opTPFHRLxrELBJ3ntPRPoey+cXXTPc=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=tguT7YBVQ2IGGHiXN0oAaLCrE1b+DLaytnxQYh4vXczjpcjyoaOrvJ7VSov1S5aXsDp1ph0YM1oB34r1TbJUG8yiQGNdIPbgIViU4/XLZLwMLuEIvTKESsNuYMkp7HcfH5rLiCb1B09iLdYDyyzgAyaYrepYItk5q36UJ/+ihTc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=google.com;\n spf=pass smtp.mailfrom=google.com;\n dkim=pass (2048-bit key) header.d=google.com header.i=@google.com\n header.b=kRjBf64B; arc=none smtp.client-ip=74.125.82.53","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=google.com; s=20251104; t=1776007485; x=1776612285;\n darn=vger.kernel.org;\n        h=in-reply-to:content-disposition:mime-version:references:message-id\n         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;\n        bh=hxVEU8M9tLLC0GDPV7iNVKeKt6wxmMr9DFDIGX2wN90=;\n        b=kRjBf64BDWzh7DgbEVlOGAtaY/CcaBWlGhdNobZK3zHHe3JUt3KjWzs2asheWQi/SQ\n         HXuScs0sO54saCU+20fHNY0/XmWLh7xAo4MDvYDcmvIwXA2W030NVvywqHbLr3G6op0q\n         acWijT1nY7xqKb3+WbJlFJioYppdJMJB0WFRN0K8KBIlf15txezCcvCXIca17nugQAbl\n         RJ3Okb9lZS7tivFpnf5b0GLDqxF9pC3h2XC3KjahlDTZUGAn8Nlup1MUpHdZibwP8uJe\n         r7Kd+Xs1fNbe4Nz192F1i90Q27rzLGEqKgth3WB4dk52EtxMJG2WKrC/iDt0wioNu+o0\n         mtoQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1776007485; x=1776612285;\n        h=in-reply-to:content-disposition:mime-version:references:message-id\n         :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc\n         :subject:date:message-id:reply-to;\n        bh=hxVEU8M9tLLC0GDPV7iNVKeKt6wxmMr9DFDIGX2wN90=;\n        b=NRxRhQe7MNoRIlDOa5/04UtDO8g2cNMJaQkytICbRycKYpstPArNN1KQHr0UDEuYxu\n         lyEizIoAug2FLh+VtwxEzDzRTpfgfX1kJAjSYbx82JHyKo4vMmrvDM9lx/XVdbjU/4KY\n         Mgi7B6sPHxB4gqbBF+lyU06tBNCtbUIsK35CwKQxaeWBVerMKlBWraiznql4Z16kPCeE\n         I49Co1JwyPY45yvaqDr8a2UZP2LTigCNX3ljjlQungcozadexq8/nGPiE0uj/jAi4rJn\n         5dq1MiJXHshMjKZkbth8tue0TL5IxLvmUKnWghhMPFgQ41d6cWjT4Rlf7o63kOiaI8xa\n         VlGg==","X-Forwarded-Encrypted":"i=1;\n AJvYcCWdKO4YkgCkubCkRncThwNxS5AOl7Uusn4CelBfGUwB3PyS0d8Om2bOo3kR+QAaYCP67w6sLdih60w=@vger.kernel.org","X-Gm-Message-State":"AOJu0YzxtVC9gu8Oo4fPckbIwaNrFEMFTjIV5MEqdJ4/MY1i29Z+qDXH\n\tHSehHRzPMI/FdaTCLcOwgnnF8446GtGPrzlshnrjQ1hflrYW103Nj//1YIeJRyVmAw==","X-Gm-Gg":"AeBDieukm7eZWTVFxHYF+EHy0f5r1p3+co7BsUm8MeKTorUNAEIYLL91saHTrg06syW\n\tCgMNZsMb6gmrfum6lJ53gtlm4YoFcg0iNe6ZxA0E5NLgeFzdCuzGmEfb7rNziH1ZxvjT6OmcZ/+\n\tcMh1DERUA733VrVgZgACvlGp396VUaCI2NKz5s8ohhtqSmWX0bep5xWz37HeQ3WYRgftHFpjxVe\n\ttuEo6UPBKu3WR2Ddg04+G1ugFFGOXMny0CYKTf8bKYZr0Re/V+WKwKdhQ9GFk+RnIujIxfomb1A\n\tBTYyMqAXE8SL/m1rmkyqg2O0bSg11oDdgWyJ4n7dOoayBIvEA5Gmvk2r4NvZLJQ7JAjbVOEQPK1\n\tg4g4750/d5JQOnECrwD9/HxPbx3jKVlerpD8PNXpxNewrJgb7qf6ZiIvQBS1TXNm1PvwOYHa7NF\n\tbdRUdQWoQr2wioC4S7HeyyvI5AXfWIZckl/jSH7/zeuNpNmBcbnet93ww4EvVDl1gXsiElqxr3","X-Received":"by 2002:a05:7022:211:b0:12c:3d1c:b317 with SMTP id\n a92af1059eb24-12c3d1cb56dmr155191c88.2.1776007484428;\n        Sun, 12 Apr 2026 08:24:44 -0700 (PDT)","Date":"Sun, 12 Apr 2026 08:24:39 -0700","From":"Igor Pylypiv <ipylypiv@google.com>","To":"Niklas Cassel <cassel@kernel.org>","Cc":"Damien Le Moal <dlemoal@kernel.org>,\n\t\"Martin K. Petersen\" <martin.petersen@oracle.com>,\n\tJohn Garry <john.g.garry@oracle.com>,\n\tXingui Yang <yangxingui@huawei.com>, linux-ide@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","Subject":"Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA\n PASS-THROUGH commands","Message-ID":"<adu5N3dSydy1uGXM@google.com>","References":"<20260410231519.951971-1-ipylypiv@google.com>\n <adt3JqwFcDx-Xe30@fedora>","Precedence":"bulk","X-Mailing-List":"linux-ide@vger.kernel.org","List-Id":"<linux-ide.vger.kernel.org>","List-Subscribe":"<mailto:linux-ide+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-ide+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<adt3JqwFcDx-Xe30@fedora>"}}]