From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnvIw-0008W5-Bn for qemu-devel@nongnu.org; Mon, 10 Nov 2014 15:11:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnvIq-0001Fu-6Y for qemu-devel@nongnu.org; Mon, 10 Nov 2014 15:11:14 -0500 Received: from cantor2.suse.de ([195.135.220.15]:46049 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnvIp-0001Fb-W2 for qemu-devel@nongnu.org; Mon, 10 Nov 2014 15:11:08 -0500 Message-ID: <54611BD9.6020105@suse.de> Date: Mon, 10 Nov 2014 21:11:05 +0100 From: Hannes Reinecke MIME-Version: 1.0 References: <1415634775-4288-1-git-send-email-hare@suse.de> <546104B3.6020707@redhat.com> In-Reply-To: <546104B3.6020707@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCHv2] esp: Do not overwrite ESP_TCHI after reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 11/10/2014 07:32 PM, Paolo Bonzini wrote: > On 10/11/2014 16:52, Hannes Reinecke wrote: >> After a reset ESP_TCHI should contain the unique ID >> of the chip. This value will be overwritten with the >> current tranfer count if the transfer count has >> previously been set. >> So we should always return the chip id if ESP_TCHI >> has never been written to. >=20 > What if ESP_TCHI was written 0? Why should it return the chip id? >=20 It's a complex thing. The documentation says 'ESP_TCHI returns the chip id until been written to'. And ESP_TCHI is strictly speaking only valid if the 'Features enabled' bit is set in ESP_CFG2. (Not that the driver checks this). To handle it correctly we would need to add a flag whenever ESP_TCHI is written to, but I thought it'd be slightly too much. Plus we're reloading the ESP_TCHI register anyway whenever a transfer is started. > Can you explain exactly what sequence of register reads/writes leads to > the bug? >=20 CMD RST DMA CMD NOP -> ESP_TCHI should contain chip_id, but doesn't. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: J. Hawn, J. Guild, F. Imend=F6rffer, HRB 16746 (AG N=FCrnberg)