From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHXCV-00084l-OO for qemu-devel@nongnu.org; Tue, 21 Jul 2015 09:03:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHXCP-0003sz-Vi for qemu-devel@nongnu.org; Tue, 21 Jul 2015 09:03:15 -0400 Received: from mail-vn0-f41.google.com ([209.85.216.41]:34687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHXCP-0003sr-Sg for qemu-devel@nongnu.org; Tue, 21 Jul 2015 09:03:09 -0400 Received: by vnds125 with SMTP id s125so35197300vnd.1 for ; Tue, 21 Jul 2015 06:03:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <55AE414E.6070505@redhat.com> References: <1437416961-26348-1-git-send-email-jsnow@redhat.com> <1437416961-26348-3-git-send-email-jsnow@redhat.com> <55AE414E.6070505@redhat.com> From: Peter Maydell Date: Tue, 21 Jul 2015 14:02:49 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PULL 2/3] ahci: Force ICC bits in PxCMD to zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Stefan Fritsch , John Snow , QEMU Developers Archived-At: List-Archive: On 21 July 2015 at 13:55, Eric Blake wrote: > On 07/21/2015 05:38 AM, Peter Maydell wrote: >> On 20 July 2015 at 19:29, John Snow wrote: >>> From: Stefan Fritsch >>> >>> The AHCI spec requires that the HBA sets the ICC bits to zero after the >>> ICC change is done. Since we don't do any ICC change, force the bits to >>> zero all the time. >>> >>> This fixes delays with some OSs (e.g. OpenBSD) waiting for the ICC bits >>> to change to 0. >> >> This change provokes a lot of clang sanitizer warnings: >> >> /home/petmay01/linaro/qemu-for-merges/hw/ide/ahci.c:288:49: runtime >> error: left shift of 15 by 28 places cannot be represented in type >> 'int' >> >> PORT_CMD_ICC_MASK is defined as >> >> #define PORT_CMD_ICC_MASK (0xf << 28) /* i/f ICC state mask */ >> >> which shifts into the sign bit of a signed integer. > > Should be fixable by using (0xfU << 28), right? Yes, though it assumes that if you say "~PORT_CMD_ICC_MASK" you're happy to only get a 32-bit mask. 0xfULL would avoid that (see discussion on the other thread with Paolo about the PPC similar issue.) -- PMM