From patchwork Fri May 5 19:46:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 98671 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp292714qge; Fri, 5 May 2017 12:48:23 -0700 (PDT) X-Received: by 10.98.75.6 with SMTP id y6mr12273241pfa.157.1494013703892; Fri, 05 May 2017 12:48:23 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 144si6012850pfa.118.2017.05.05.12.48.23; Fri, 05 May 2017 12:48:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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 stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752409AbdEETsV (ORCPT + 6 others); Fri, 5 May 2017 15:48:21 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:61402 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754699AbdEETsQ (ORCPT ); Fri, 5 May 2017 15:48:16 -0400 Received: from wuerfel.lan ([78.42.17.5]) by mrelayeu.kundenserver.de (mreue002 [212.227.15.129]) with ESMTPA (Nemesis) id 0MdzeH-1dPcZ63S05-00Pa9w; Fri, 05 May 2017 21:48:13 +0200 From: Arnd Bergmann To: Ben Hutchings Cc: stable@vger.kernel.org, Arnd Bergmann , Greg Kroah-Hartman Subject: [PATCH 3.16-stable 29/87] tty: nozomi: avoid a harmless gcc warning Date: Fri, 5 May 2017 21:46:47 +0200 Message-Id: <20170505194745.3627137-30-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20170505194745.3627137-1-arnd@arndb.de> References: <20170505194745.3627137-1-arnd@arndb.de> X-Provags-ID: V03:K0:RGXyhYII32KydToPKBBF/kk3tAKKglaZ3sx6QuwtNuSgB0tiHca yzXCTIIB/QwFqZNlbHHKpfaTgrhy+mObPYI6zgB9W9kVhKmiT6zMy8wDfzOWntcVdDitc+a 0wiG+gxKelzj3qEnMPFk18PfcDGLBJ14g5xCJGEeiaMmSkhTKz1fhyux0CeGQztSkE/7omE PKhsjvlPbtZA553UB/A+w== X-UI-Out-Filterresults: notjunk:1; V01:K0:tGoGCKseEcQ=:qmB0kDZPn0s+2bvLXtDy1T qGkYQKnfBK6sRaBmL4MWipHY1dPmk2pFq2er/kbdyro3BD+gzjC3MvwJGkuKYItTmSjJgCvs8 WGzzgzSmau17tu5xQglPRZQw6loh3avqzHlnkpiLdmE7Rmh0tiqKdLfxLa4Klg9/r5QldBRIt 4KdMF8lPxKYJoFAndbn3uiAAAhDEfQ6Irfa05h/Ixbp4BLQt6Dl0iPo1heRJpNotcJlUHQufV MXZA1XYT0rKL9FvasNPKb9rc40sqvg/WgYWXSEIWeUYyUSMXjPuKoHTGFaKkjDqoK0LiOsAWu cCFNs8ggpCFigsovBADMUL+AM/8TbGLdO/5+8IVhh4818kDBw5QqZ9HUcZMkYgHNj3dwlbmTX 0syjZwX8xUXw8s8AKlhoqXbR8vrPNnA5N88PbVvCs8IL2fQz3qQBI/bbXChctwwjN4UTMUnl5 nw4tfmmeyRsCLbGMtTtDR6xFzmfcWZ5z4q6E2Gl4UyxgcSc0nucMOXzkU0s2Sq5NdAs117UP4 1pYFLnexqzIzb0TkrXHfqQwL3qkJkvQ2H9uHAulSrdnlI2eOFN5mJ6QMwZieICvXmucFkvNiZ /VcCCmA2bEqMyTTPUEnvAKc5FuL7/HSfj8b8NuHDBDjDjddH25XHMl/KWcuj1ELmpChLNu6Od wUOTTvB+xfwgNYdBNG19z7hToQuPtIOMPb7d457wM+RJJvm/BgYv5b7sbnBuS/etuLE4= Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Commit 12ad7e7221c80094be100a0e564f0d65775017dc 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: Greg Kroah-Hartman Signed-off-by: Arnd Bergmann --- drivers/tty/nozomi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.9.0 diff --git a/drivers/tty/nozomi.c b/drivers/tty/nozomi.c index cd0429369557..b5b1b195ff2c 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)) {