From patchwork Mon Jun 19 18:32:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105910 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1010900qgd; Mon, 19 Jun 2017 11:40:54 -0700 (PDT) X-Received: by 10.84.178.101 with SMTP id y92mr31165537plb.116.1497897654487; Mon, 19 Jun 2017 11:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497897654; cv=none; d=google.com; s=arc-20160816; b=gi3VKHOV5YRTAWIqbfIHPXMf0QB9lcgg2WxPybEK7/Zurhngrd2KMwp80ZAWTm+rrZ 4W8kHstTNqyVgiSn9/sdKJDL/S9wsbF+ETdANJ+ctvVWs8hiYkvfSiKxX+BL0vn6sfTo X63qa7sYi6tkAFppqPlCkYdqT0TMhcS/uGBQcN4h9c16QyPDdsVGsnqKFSNW4AxwHl2L XOZ+4xbk1LyLEVLW6diwb0xwaOYz3RcxF8w9/QCqmeSeGFP90SNrezLNfukFtAPhDDq4 j8Vx8Aj9M8yzOGprRu9J3RSr7HSDWLUikKCG9hWrE2608+H+Ymmb+rycxNjP72y4+3jM 11rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=lrvb8OCbTVi++XZWR5iWjGMG188oTXUrVACMZ2UxHJ4=; b=FGbI52EMwKmrN7VQ/VOWvAkM9wo2d+58kusn1y4Al88AHk3cNc70iQ4BVQk/vQenIc XO2PebOgPp5SSLw3+P/QeVCu3+7y0W68Ihb9zQZYbLyAQkrjeRbfGvsCngpQ8TaWfsW2 nq4X0SbibAIeJoGpd9deCq4XdjiYt9J8O0n/rPnkapqtt52KGA6DdmxEI5iO6iNTPRY3 NJ8WYXIm6uo1b8R8LzwIqiYhzC+FhNxg0IFsCUliCrpu3Tk10X07chUXv4kviKRhWi2u zwGohlxHT5gXobHX9Tac8f2gB51iJpQ61bMh/N7gTCW+jV7Z8EndAt/KmpJOD+j0276f E1xA== 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 r85si8790477pgr.13.2017.06.19.11.40.54; Mon, 19 Jun 2017 11:40:54 -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 S1753742AbdFSSkv (ORCPT + 25 others); Mon, 19 Jun 2017 14:40:51 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52793 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753873AbdFSSkt (ORCPT ); Mon, 19 Jun 2017 14:40:49 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIY1E6015116; Mon, 19 Jun 2017 20:34:01 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , Willy Tarreau Subject: [PATCH 3.10 250/268] tty: nozomi: avoid a harmless gcc warning Date: Mon, 19 Jun 2017 20:32:29 +0200 Message-Id: <1497897167-14556-251-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit a4f642a8a3c2838ad09fe8313d45db46600e1478 upstream. The nozomi wireless data driver has its own helper function to transfer data from a FIFO, doing an extra byte swap on big-endian architectures, presumably to bring the data back into byte-serial order after readw() or readl() perform their implicit byteswap. This helper function is used in the receive_data() function to first read the length into a 32-bit variable, which causes a compile-time warning: drivers/tty/nozomi.c: In function 'receive_data': drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized] The problem is that gcc is unsure whether the data was actually read or not. We know that it is at this point, so we can replace it with a single readl() to shut up that warning. I am leaving the byteswap in there, to preserve the existing behavior, even though this seems fishy: Reading the length of the data into a cpu-endian variable should normally not use a second byteswap on big-endian systems, unless the hardware is aware of the CPU endianess. There appears to be a lot more confusion about endianess in this driver, so it probably has not worked on big-endian systems in a long time, if ever, and I have no way to test it. It's well possible that this driver has not been used by anyone in a while, the last patch that looks like it was tested on the hardware is from 2008. Signed-off-by: Arnd Bergmann Signed-off-by: Willy Tarreau --- drivers/tty/nozomi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/drivers/tty/nozomi.c b/drivers/tty/nozomi.c index d6080c3..ce2e5d5 100644 --- a/drivers/tty/nozomi.c +++ b/drivers/tty/nozomi.c @@ -823,7 +823,7 @@ static int receive_data(enum port_type index, struct nozomi *dc) struct tty_struct *tty = tty_port_tty_get(&port->port); int i, ret; - read_mem32((u32 *) &size, addr, 4); + size = __le32_to_cpu(readl(addr)); /* DBG1( "%d bytes port: %d", size, index); */ if (tty && test_bit(TTY_THROTTLED, &tty->flags)) {