Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp3265747rwr; Sun, 7 May 2023 08:05:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6xP/5Yu+RMYg+uDu6WBnDEzcr4OZHOb0UnLKeI8QVr9E8vjV5iINFWMcsfO3DYnkKHCpGQ X-Received: by 2002:a05:6a20:d48c:b0:f6:15f3:ca36 with SMTP id im12-20020a056a20d48c00b000f615f3ca36mr7384834pzb.50.1683471949611; Sun, 07 May 2023 08:05:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683471949; cv=none; d=google.com; s=arc-20160816; b=WUim1LA4do9RddZrQtkqKdbRaL0SbhWzIAGg5xt2WrudBguyNwFzz4IUTkvUqdEsJT n8gD9laIqGQWrAyF2c7PFM0wJsnaS28s2q8gahURMLe8RLx2lNPday93ioV1GuCZgDY4 q2lmLiofdlIEXqcNBqT0oQ2ySTqeBOYIyucMgJKt7q/4OP7bp2JVVZX0KOo3LiWyanSK pD7O8kB0EURODT4yAeamINkIFXjcNQsEF3R+A4z0l5fmQ6Jb9p/21oKBzAePGH+2Pr1n 4vjR10SjR6sX09Gs16JYwkec+Je9NWSXjnSQgDYtusDlLldvPdcoidGNrUf5LXAlzh2D FM3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=OjPoeIALVILW7jVNBv+s9hzNgepiL+gQ0POUG1ycSkw=; b=ncds38JwDO2FcQBYA4Zr986IsKmSoS1Z9a2gJ2/mIsGRJfkSm2/jie/7WnN25pl0om PP6Wa2g2jB7KtXRJYkQbvi8YmAxnfsw33dUPL9DqBPpvs7kxa9teVJKALBKdde0SjKBj uC5se4zx0hpogwqhcPrhVd6FM02E1LKJks6BrvGQyDpzVTrmzcD0Q/DxWujbdw+K3tcX /DHtFC2P8qEJp6QS98T1FefAgI/H9kcfmkTaes4oj9VNgKce9eleeyfDcbnTbIfthqxI mwGpaqAw3gmDJ47b3LkcrbMEgIVujbv2IhpY3AMVhD5+RCcv604+VEvpz63OQRozUM6L I0AQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=r1RM+995; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w7-20020a626207000000b00627e8781dbfsi6430518pfb.266.2023.05.07.08.05.26; Sun, 07 May 2023 08:05:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=r1RM+995; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230211AbjEGOvu (ORCPT + 99 others); Sun, 7 May 2023 10:51:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbjEGOvs (ORCPT ); Sun, 7 May 2023 10:51:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CB505B8B; Sun, 7 May 2023 07:51:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8DD3A60EA8; Sun, 7 May 2023 14:51:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF7EDC433D2; Sun, 7 May 2023 14:51:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683471106; bh=6Uz2eGplQeLWHfzSTBT1n6hG4hAqwi661BYrpEeRNGA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=r1RM+995JVQuFTyIWjf/iW2TSPddyJpJmvdFZ3n1bhJhAy5fC/8h0mWu5KBB9+aBh Nr/AzCNMftFUvehr0EgA27DyczWlCWmW48igY+uze6/rXtVoB856+iHMDZyZ1DEIz6 niA59lNU1e3ougA8KMj5g400nP47u08AqtqFoZUYNRpEYuu396+NJz8ZPwZTndsfML jw71KMA7JR9OmotYgBbl/L3uaMNm14K/7/4taNhoyHxA6tgD8hD8vDYwBn4DAG3xfs Zf8xwAijacW2P92E99EQZO1Vb/Y78I05aCAi3lRFN2IrXDoCQ7eGUTPn+kqJayuBoo GhoV9h6uQkJ6w== Message-ID: Date: Sun, 7 May 2023 23:51:42 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2] ata: libata-scsi: Fix get identity data failed To: yangxingui , jejb@linux.ibm.com, martin.petersen@oracle.com, john.g.garry@oracle.com Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, linuxarm@huawei.com, prime.zeng@hisilicon.com, kangfenglong@huawei.com References: <20230505025712.19438-1-yangxingui@huawei.com> <291f1d97-9195-45ac-8e12-058f5c797277@kernel.org> <02d36ee9-cdad-454d-d822-95442d7bd67b@huawei.com> Content-Language: en-US From: Damien Le Moal Organization: Western Digital Research In-Reply-To: <02d36ee9-cdad-454d-d822-95442d7bd67b@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/05/05 18:06, yangxingui wrote: > > > On 2023/5/5 16:17, Damien Le Moal wrote: >> On 2023/05/05 11:57, Xingui Yang wrote: >>> The function ata_get_identity() uses the helper ata_scsi_find_dev() to get >>> the ata_device structure of a scsi device. However, when the ata device is >>> managed by libsas, ata_scsi_find_dev() returns NULL, turning >>> ata_get_identity() into a nop and always returns -ENOMSG. >> >> What do you do to hit the issue ? A while back for me it was the queue depth >> setting causing problems. As Garry mentioned, this led to patch 141f3d6256e5 >> ("ata: libata-sata: Fix device queue depth control"). > Attempt to return the correct value at ata_scsi_find_dev() instead of > NULL, when the ata device is managed by libsas? That I understand. My question is *what* user operation/command triggers this ? Because on my test setup, under normal use, I do not see this issue (beside what was already corrected with the queue depth control). Is the issue showing up when using passthrough commands only ? -- Damien Le Moal Western Digital Research