Re: [PATCH v2 0/8] hw: Convert various reset() handler to DeviceReset

[Philippe Mathieu-Daudé]

On 10/10/19 3:05 AM, Li Qiang wrote:
> Philippe Mathieu-Daudé <address@hidden <mailto:address@hidden>> 于 
> 2019年10月10日周四 上午3:54写道：
>
>     Hi Li,
>
>     On 10/9/19 4:28 AM, Li Qiang wrote:
>      > Philippe Mathieu-Daudé <address@hidden
>     <mailto:address@hidden> <mailto:address@hidden
>     <mailto:address@hidden>>> 于
>      > 2019年10月8日周二 下午10:47写道：
>      >
>      >     Since v1:
>      >     - Removed the pci-host devices
>      >
>      >
>      > Hello  I want to know why  remove this?
>
>     I haven't removed the devices, I simply remove the patches converting
>     them to DeviceReset, 
>
>
> Yes, I mean the patches.
>
>     basically because I've not enough time to check if
>     the are on a bus that would reset them. 
>
>
> IIUC, they are right.
>
>     I added these devices on my TODO
>     list for later, so meanwhile the other devices can be easily reviewed
>     and merged. When few patches from a series are not reviewed or
>     incorrect, sometime the rest of the series is not merged, so I
>     prefer to
>     split it and get these patches merged.
>
>
> As far as I can see, most of the devices' usage of qemu_register_reset 
> function can be
> convert to 'dc->reset'. In the main function.
>
> qemu_register_reset(qbus_reset_all_fn, sysbus_get_default());
>
> The 'qbus_reset_all_fn' calls 'qbus_reset_all' from the 'main-sys-bus'. 
> Then 'qdev_reset_one'
> will call 'device_reset'. So IIUC every bus attached to 'main-sys-bus' 
> can be reset through 'dc->reset'
>
> So I'm quite sure most of the cases that devices use 
> 'qemu_register_reset' can be changed to 'dc->reset'.
> Seems you're busy,  If you don't mind, I can do some of the work to 
> convert 'reset' callback(not a patchset, one by one).

I guess we are all busy ;) I'm just trying to prioritize here.
This series is not very important because what we have today works, and 
I would rather not introduce regressions. What happened then is it is 
the 3rd time at least I get confuse with the qemu_register_reset() 
function while reviewing code. Then my rule of thumb is if an 
improvement takes less than 1h, then I just do it and keep going, else 
if I postpone it I'll never go back to it. When a series start to take 
too much rework it means I might started it wrongly, or I underestimated 
the time required. Time that is taken of other more important tasks.
Today I prefer merged a subset of the series that is correct, rather 
than aiming for the whole and never get it merged.

If you are interested in respining/fixing the pci-host devices I'd be 
very thankful! I appreciate your help (and reviews).

Regards,

Phil.

PD: I'll respin as v3 with your tags and the PIIX4_IDE fix.

>      >
>      >     - Removed the vmcoreinfo conversion (elmarco) but add a comment.
>      >     - Added Igor's R-b tag.
>      >
>      >     Following the thread discussion between Peter/Markus/Damien about
>      >     reset handlers:
>      > https://www.mail-archive.com/address@hidden/msg617103.html
>      >     I started to remove qemu_register_reset() calls from few
>     qdevified
>      >     devices (the trivial ones).
>      >
>      >     Regards,
>      >
>      >     Phil.
>      >
>      >     v1:
>     https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06367.html
>      >
>      >     Philippe Mathieu-Daudé (8):
>      >        hw/acpi/piix4: Convert reset handler to DeviceReset
>      >        hw/isa/piix4: Convert reset handler to DeviceReset
>      >        hw/ide/piix: Convert reset handler to DeviceReset
>      >        hw/ide/sii3112: Convert reset handler to DeviceReset
>      >        hw/ide/via82c: Convert reset handler to DeviceReset
>      >        hw/isa/vt82c686: Convert reset handler to DeviceReset
>      >        hw/input/lm832x: Convert reset handler to DeviceReset
>      >        hw/misc/vmcoreinfo: Document its reset handler