Am 17.04.2013 08:29, schrieb Julio Guerra: > 2013/2/25 Andreas Färber <andreas.faer...@web.de>: >> Am 25.02.2013 12:20, schrieb Alexander Graf: >>> >>> On 16.02.2013, at 16:08, Julio Guerra wrote: >>> >>>> The software reset of a PReP machine should reset the entire system >>>> and not only the processor. It occurs when changing the 7th bit of >>>> port 0092 from 0 to 1. >>>> >>>> Adding a new variable in PReP's sysctrl_t to store the soft reset bit >>>> makes possible to be compliant with PReP specification : >>>> * reset the system when changing soft reset bit from 0 to 1. >>>> * the soft reset bit value is 1 after a soft reset. >>>> * Port 0092 is read/write. >>>> >>>> qemu_system_reset_request() does the required job (calling the reset >>>> handlers) when the software reset is needed. >>>> >>>> reset_irq is no longer needed, the CPU reset (calling ppc_prep_reset) >>>> is called when qemu_system_reset calls every reset handlers. >>>> >>>> Signed-off-by: Julio Guerra <gu...@julio.in> >>> >>> Andreas, could you take this one through the prep queue please? >> >> It's PReP only, so I intend to handle it. But apart from checkpatch.pl >> style problems (that I could fix up myself) this is touching on the same >> soft reset topic that I am awaiting the outcome for x86. >> >> The issue of returning endianness bit for 0x0092 is independent of that >> and could be split out. I want a qtest case though, therefore my >> interest in Markus' series. Could become a separate prep-test though. >> > > Sorry to insist but is there something wrong with this patch ?
Yes, quite frankly I already indicated that it is inacceptable as-is: * Coding Style issues to be fixed * No agreed solution for Soft Reset yet that I am aware of * Conflicting RFC patchsets by Hervé wrt systemio If you could take a look at the latter yourself and provide a trimmed-down patch, that would speed things up. Regards, Andreas
