From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHbY3-0004od-GA for qemu-devel@nongnu.org; Tue, 21 Jul 2015 13:41:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHbY0-0002FQ-9E for qemu-devel@nongnu.org; Tue, 21 Jul 2015 13:41:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHbY0-0002FJ-3H for qemu-devel@nongnu.org; Tue, 21 Jul 2015 13:41:44 -0400 Message-ID: <55AE8454.6050604@redhat.com> Date: Tue, 21 Jul 2015 13:41:40 -0400 From: John Snow MIME-Version: 1.0 References: <1437416961-26348-1-git-send-email-jsnow@redhat.com> <1437416961-26348-3-git-send-email-jsnow@redhat.com> <55AE414E.6070505@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Peter Maydell , Eric Blake Cc: Stefan Fritsch , QEMU Developers Archived-At: List-Archive: On 07/21/2015 09:02 AM, Peter Maydell wrote: > 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 b= its >>>> 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? >=20 > 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.) >=20 I think we're happy to admit it's a simple 32bit mask, since it's just a 32bit field and I can't imagine us needing it for any other purpose right now. I'd be worried that ~(0xfULL) would be pretty much the wrong thing in nearly all cases. Same for ~..UL. I'll send a quick patch for Eric's suggestion. > -- PMM >=20 Thanks, --js