From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60803 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oq9zk-0000uz-A8 for qemu-devel@nongnu.org; Mon, 30 Aug 2010 15:27:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oq9zD-0003xl-Hr for qemu-devel@nongnu.org; Mon, 30 Aug 2010 15:25:45 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:53952) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq9zD-0003xL-Ff for qemu-devel@nongnu.org; Mon, 30 Aug 2010 15:25:43 -0400 Received: by qwh5 with SMTP id 5so5433929qwh.4 for ; Mon, 30 Aug 2010 12:25:42 -0700 (PDT) Message-ID: <4C7C05B8.5080104@codemonkey.ws> Date: Mon, 30 Aug 2010 14:25:44 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 5/5] RFC: distinguish warm reset from cold reset. References: <0a460e01cca4fa24f446c7a715fe6df17d0be9ed.1283152674.git.yamahata@valinux.co.jp> <4C7B70E7.80906@redhat.com> <4C7BAC17.3030305@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: glommer@redhat.com, qemu-devel@nongnu.org, Isaku Yamahata , alex.williamson@redhat.com, avi@redhat.com, Paolo Bonzini On 08/30/2010 02:16 PM, Blue Swirl wrote: > On Mon, Aug 30, 2010 at 1:03 PM, Anthony Liguori wrote: > >> On 08/30/2010 03:50 AM, Paolo Bonzini wrote: >> >>> On 08/30/2010 09:49 AM, Isaku Yamahata wrote: >>> >>>> +/* those two functions are obsoleted by cold/warm reset API. */ >>>> [qemu_register_reset/qemu_unregister_reset] >>>> >>> Are they? >>> >> Yes, but introduce more reset functions isn't the right approach. >> >> Reset should be a method of the device tree, not a stand alone function. >> > In theory the reset tree may be very different from device tree. In > practice the reset tree is probably very flat (global reset signal, a > few bus reset signals) so device tree approach may get the same > results. > Well the device tree doesn't really have to be a tree :-) My thinking if we need to support custom reset propagation is that we have the current reset() handler return 0 to propagate to children, < 0 on error, and > 0 to not propagate to direct children just as we do with the walkers. In the case of > 0, the device can choose to propagate to any device that it knows about independent of the default walking order. This makes the device tree a directed graph whereas the transversal path can be arbitrarily custom. The only questions in my mind are, do we truly need this and do we need more than a single type of reset. We could make this almost arbitrarily complicated if we wanted to but we should try to keep things simply unless there's a compelling reason not to. Regards, Anthon Liguori > IIRC on some HW ages ago the CPU could initiate an external device > reset (without resetting the CPU) but in that case the board caused > also CPU to be reset so it was useless. > > One way to model the disjoint reset trees would be to use an explicit > qemu_irq signal for reset. It's a bit complex to set up compared to > the almost flat tree we want though. > >