Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp698901pxa; Tue, 11 Aug 2020 12:44:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4rhOZYHX4YQszXH4YZulV86lSyHbZjWVGkGlxZOA3oXXExYxhQEtweGzFRFtpljkPiG4z X-Received: by 2002:a05:6402:1e5:: with SMTP id i5mr26843518edy.194.1597175067532; Tue, 11 Aug 2020 12:44:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597175067; cv=none; d=google.com; s=arc-20160816; b=c1SEYoDkenmjHZK/tXnN26RwPC6PDxRF47F4JQOxHAX2y7lNTTdPLcLE1xkAbVKSc4 Aw1lCroNBR3QPmEzsTkE9uLCq6Gx1B8yx0OPeJeNwHtlxiJQfvx0+Qnd3v/rrRc+DIhp LogZds6KR7E+/6qn59kkCdk5nkd1j3gPuwpRDwynVN//KKJO7k9QwiTmC028Os6EoWRT cQPIBTcuHxTzVPhRlKSybBZ7Y5NaYLFPQixbfCQ65wOZ9KJ8QFIPk7kDschSxCIJjEkc dMdb7qiqOuBzcPofz8LHBibswjw/2/4GctuwyNwGmMZ/Z7+F+Q/4guOdaExvcUlmNOsE eHBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=QcT4droLiVrBm+iCY51P7DHwHTBeWX2sFLbbRd9QfEw=; b=Ft76AZLFl+wfpYQTbwDViIGycxyoNyQmd2rQZowKIxB0pU68RGF1jr4ziIfCIYUHzP agmQvHwtcQNmukKJKttNMdlvBcI140VRJIP8XEuS+2za6GI1QHz6UI2It6TcHdRA8OwK WtuZNqAljhexr0BiTpXmDv7xoCBgpzIaxHj8/O0u/1aJw0nAJdMZL3wmn+TJCkREf+jN PA+elipwXdcRZzh2HUP6+MgIG/sf0/aP2R7CUUdXzVIEF9DPPD5Tg4C03DyT0fgBc7if MjmHeV43lD8N94AkptZIx87RG0Mz29w2wsb2Dgshm5tWOFD/tDHFwrDPyuPco0lh6SNA r9Ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si13505238edq.178.2020.08.11.12.44.04; Tue, 11 Aug 2020 12:44:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726127AbgHKTnV (ORCPT + 99 others); Tue, 11 Aug 2020 15:43:21 -0400 Received: from netrider.rowland.org ([192.131.102.5]:49717 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726068AbgHKTnU (ORCPT ); Tue, 11 Aug 2020 15:43:20 -0400 Received: (qmail 345373 invoked by uid 1000); 11 Aug 2020 15:43:19 -0400 Date: Tue, 11 Aug 2020 15:43:19 -0400 From: Alan Stern To: Tom Rix Cc: gregkh@linuxfoundation.org, acozzette@cs.hmc.edu, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH] USB: realtek_cr: fix return check for dma functions Message-ID: <20200811194319.GB344152@rowland.harvard.edu> References: <20200811151505.12222-1-trix@redhat.com> <20200811160348.GD335280@rowland.harvard.edu> <1f7d5a64-f264-4fed-bf90-b64e2693652d@redhat.com> <20200811175338.GB339805@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 11, 2020 at 11:54:28AM -0700, Tom Rix wrote: > > On 8/11/20 10:53 AM, Alan Stern wrote: > >>> Instead of changing all these call sites, wouldn't it be a lot easier > >>> just to change rts51x_read_mem() to make it always return a negative > >>> value (such as -EIO) when there's an error? > >>> > >>> Alan Stern > >> I thought about that but there was already existing (retval != > >> STATUS_SUCCESS) checks for these calls. > > The only values that routine currently returns are > > USB_STOR_TRANSPORT_ERROR, -EIO, and 0. None of the callers distinguish > > between the first two values, so you can just change the first to the > > second. > > > > Note that STATUS_SUCCESS is simply 0. > > Yes, i noted all of these already. My change is consistent with the > existing correct checks.? consistency is important.? returning a neg > value to reuse the exiting check should mean the STATUS_SUCCESS != 0 > checks are changed to neg check. Do you mean the "retval == STATUS_SUCCESS" checks? Those checks would end up doing exactly the same thing as they do now, since USB_STOR_TRANSPORT_ERROR and -EIO are both different from 0. Yes, it is true that consistency is important. But correctness is more important than consistency. >? i can do this larger change if > required. Let me put it this way: Suppose you changed the USB_STOR_TRANSPORT_ERROR in rts51x_read_mem() to -EIO, without changing anything else. Wouldn't that fix the problem reported by the clang static analysis? If not, why not? Alan Stern