Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3130960imm; Sun, 3 Jun 2018 20:33:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIyVSpyG52aVlhbcb1585eON2D/VdBakymKu+rr8UfW6YrJIGEmVQfruyUxmdxOZYFz1aft X-Received: by 2002:a65:4204:: with SMTP id c4-v6mr15609893pgq.26.1528083205507; Sun, 03 Jun 2018 20:33:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528083205; cv=none; d=google.com; s=arc-20160816; b=c6PQXce7rFNjAhTaySn5iK8tt67Z6JY+zoGWub4YI22RLGXsoUMhajKOsfNJ/IPNEm aICl/PW7eTGaxysWp5pD6CSxgydKBRda1C3WUilD55PSAmgBBk63BMngKes/SbFIbHSg OZISiVNrkXSCZ61/Iw/8Y43zydAXFfWYJD/VBjfh7ktCj32jtx8cJEYv3c2mn0YtaGfw Eq9iJMk8TSMkWik4qK1HOml9CndZW7ybYTLLS74KO24KeiXqkrwXDYrw4HF3HvCKQIY4 lkyEIFojxucLRyRD97H3B/TaJAkIm/jqItr78u8bqLPnN37S9o0OsEBBywOSWJGSNBBv CeRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from:arc-authentication-results; bh=fZX4UKalBStHvReCBJx4Bn48b8UetoiZRp09D4E/1QE=; b=rvb84Ii9x/z/MW/XTKpDgloQFINpjDi7Pd62N84kVH5oEEwHqPd0PPQJAe7JEFaKAK sMQodckiRITHroDszjtINzfRqaQRuWGEE6t6xsECfi4s1fIqmWKZAlef3YNzjEvdWv83 ZIGp8OL3XZ539rSL9FBwoavzXAqZbV/zYc/mfeFDx6NZYVkxGrV1VBHlnNKEIijujJsC oCQ3P1lJU5m7+eidj5zJpGNFYms3Fi0x/dLGgSRSUsR4OObew5C3XMFRHRkWDLZvxWPb iZyUr5kibLV6TQCdW8bdp8dEFm9oEJRqmamPB3F/eBWhBHGDqaeWtzytTp/O3UMbzVB+ Ks4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p25-v6si20198782pfi.345.2018.06.03.20.32.50; Sun, 03 Jun 2018 20:33:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751479AbeFDDcP convert rfc822-to-8bit (ORCPT + 99 others); Sun, 3 Jun 2018 23:32:15 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:5553 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751210AbeFDDcO (ORCPT ); Sun, 3 Jun 2018 23:32:14 -0400 Received: from DGGEMM405-HUB.china.huawei.com (unknown [172.30.72.57]) by Forcepoint Email with ESMTP id 18627EFC17D3A; Mon, 4 Jun 2018 11:32:10 +0800 (CST) Received: from DGGEMM507-MBX.china.huawei.com ([169.254.1.199]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0382.000; Mon, 4 Jun 2018 11:32:08 +0800 From: Nixiaoming To: "tj@kernel.org" CC: "linux-ide@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: For help, whether to check the return value of sata_scr_read should be added in sata_print_link_status Thread-Topic: For help, whether to check the return value of sata_scr_read should be added in sata_print_link_status Thread-Index: AdP7tHwsYIItW1lIR5+8myT1DH4gzQ== Date: Mon, 4 Jun 2018 03:32:07 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.88.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello I have trouble reading the code, I hope you can help guide The function sata_print_link_status in the file drivers/ata/libata-core.c checks the return value when the function sata_scr_read is called on line 3009, but does not check the return value when calling sata_scr_read on line 3011. Why are two calls handled differently? Is there any other code logic that guarantees that the 3011 line will not return an exception? drivers/ata/libata-core.c : 3005 static void sata_print_link_status(struct ata_link *link) 3006 { 3007 u32 sstatus, scontrol, tmp; 3008 3009 if (sata_scr_read(link, SCR_STATUS, &sstatus)) 3010 return; 3011 sata_scr_read(link, SCR_CONTROL, &scontrol); 3012 3013 if (ata_phys_link_online(link)) { Thanks