Received: by 10.223.164.202 with SMTP id h10csp898844wrb; Tue, 7 Nov 2017 17:08:57 -0800 (PST) X-Google-Smtp-Source: ABhQp+QPB9scD9/myo+daoWsFMjQqa74dMckCtpZBil0o5bF6QlQ1uJVib88uVjjTWdHSOZfLPrI X-Received: by 10.98.70.137 with SMTP id o9mr614549pfi.19.1510103337343; Tue, 07 Nov 2017 17:08:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510103337; cv=none; d=google.com; s=arc-20160816; b=DFK90EElKUtYrzNTTL8ASGyH5F360y6e4PbO90hP5Xw83XosGjYh9lBpfLG91pGHhO 6Qf2Gk2nmp17etVsJ2YtAH+lZaQGGNkiwsawOZpNhydgEmQD3lZOnxKwqiWGTU9BV00w T0eeHmfoY7PK1I6bxdJ+TiN+MN4rrqrX3+ODA62Hmf24QIuCH7cuWMY/W4j40jimMhu3 9YQhoUluzZFm7nWScRLXwIl9sdwhgbe+9wCHsP8ihQCnie7ipfaXgQuNz6XgiqKkDuJr e9R+Hy5EDVhmPsCC3sE3oB5xXNFPR6qSYz19SEcfSZiWT3J8tSiONeBcGi5aVOaAh6a9 lbBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=qLfOk4Wws6pvvN+NilBS/ipXRn0n88cOygbQYaEB8QA=; b=DbCTadFNv7/6kAyfCi8KrnE34NPp37PYsTRoRAkfWSYwkQ8LkC3AP0Y8cYb9QzQNO8 pcVccz5AxdqI483pSWP9/zQGYxfDIBhywQahbeb62YdaOUb6DBbtkuU6xqEWWb7EQTDR ee/wl3NjPIJhYM55ZnLiAEvcIMbXoZGNsmfNO9wJW1wAQy3igaTyGl4oOj+NsMrYNpLB ufpcoLrSPXGLA1b4trogD84XFjR/PQf8DI3x9uKtx25qVrjQ5Rslmuks6w88XmWqZ25Q 09BX9FxKtseGHT7wuy7MTjbQmTJeEnQaSQUfTylCK5z9EHCYqHLDNh2Z5ZhvkqtCGhPG antg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d69si2318946pga.99.2017.11.07.17.08.43; Tue, 07 Nov 2017 17:08:57 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756939AbdKGPmx (ORCPT + 92 others); Tue, 7 Nov 2017 10:42:53 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:60862 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751417AbdKGPmw (ORCPT ); Tue, 7 Nov 2017 10:42:52 -0500 Received: (qmail 3090 invoked by uid 2102); 7 Nov 2017 10:42:51 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Nov 2017 10:42:51 -0500 Date: Tue, 7 Nov 2017 10:42:51 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Colin King cc: Greg Kroah-Hartman , , , Subject: Re: [PATCH] USB: remove redundant assignment to temp In-Reply-To: <20171107102759.10456-1-colin.king@canonical.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 Nov 2017, Colin King wrote: > From: Colin Ian King > > The variable temp is being set at the end of each loop iteration > but this value is never read, it is either being updated in just > the case 1 block or at the end of the loop. Thus the assignment > is redundant and can be removed. Cleans up clang warning: > > drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp' > is never read > > Signed-off-by: Colin Ian King > --- > drivers/usb/host/ehci-dbg.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c > index 7fb21d01b3d0..70d4768958be 100644 > --- a/drivers/usb/host/ehci-dbg.c > +++ b/drivers/usb/host/ehci-dbg.c > @@ -838,7 +838,6 @@ static ssize_t fill_registers_buffer(struct debug_buffer *buf) > default: /* unknown */ > break; > } > - temp = (cap >> 8) & 0xff; > } > } > #endif Good catch, but the solution is wrong. The original code was mistaken; it should have said: offset = (cap >> 8) & 0xff; You can see that something like this is necessary if you consider the code path for the case where (cap & 0xff) != 1 -- the loop would just read the same capability value over and over again. Would you like to submit a revised patch? Alan Stern From 1583410225445306084@xxx Tue Nov 07 12:27:44 +0000 2017 X-GM-THRID: 1583410225445306084 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread