On Fri, Aug 09, 2019 at 10:45:43AM +0200, Damien Hedde wrote: > > > On 8/9/19 7:51 AM, David Gibson wrote: > > On Wed, Aug 07, 2019 at 11:37:51AM +0100, Peter Maydell wrote: > >> On Wed, 31 Jul 2019 at 07:33, David Gibson <da...@gibson.dropbear.id.au> > >> wrote: > >>> > >>> On Mon, Jul 29, 2019 at 04:56:29PM +0200, Damien Hedde wrote: > >>>> It adds the possibility to add 2 gpios to control the warm and cold > >>>> reset. > >>>> With theses ios, the reset can be maintained during some time. > >>>> Each io is associated with a state to detect level changes. > >>>> > >>>> Vmstate subsections are also added to the existsing device_reset > >>>> subsection. > >>> > >>> This doesn't seem like a thing that should be present on every single > >>> DeviceState. > >> > >> It's a facility that's going to be useful to multiple different > >> subclasses of DeviceState, so it seems to me cleaner to > >> have base class support for the common feature rather than > >> to reimplement it entirely from scratch in every subclass > >> that wants it. > > > > Hm, I suppose so. Would it really have to be from scratch, though? > > Couldn't some suitable helper functions make adding such GPIOs to a > > device pretty straightforward? > > > > This patch does that. A device does have to use the helper to add the > gpio. Either qdev_init_warm_reset_gpio(...) or > qdev_init_cold_reset_gpio(...) , like any another gpio.
Ah, sorry, I misunderstood.
That seems ok then.
>
> The mechanics to control the reset with gpio change is done in the base
> class and there is some state pre-allocated (and associated vmstate
> description) to it.
>
> If that's a problem I can only provide helpers and let devices handle
> state allocation and vmstate addition.
>
> Damien
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
