Re: [Qemu-ppc] [PATCH] prep: Fix software reset

[Andreas Färber]

Am 17.04.2013 08:29, schrieb Julio Guerra:
> 2013/2/25 Andreas Färber <address@hidden>:
>> 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 <address@hidden>
>>>
>>> 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