On Mon, Sep 30, 2019 at 09:29:14PM +0200, Cédric Le Goater wrote:
> On 30/09/2019 10:25, David Gibson wrote:
> > On Mon, Sep 30, 2019 at 08:11:56AM +0200, Cédric Le Goater wrote:
> >> On 27/09/2019 07:50, David Gibson wrote:
> >>> It turns out that all the logic in the SpaprIrq::reset hooks (and so
On 30/09/2019 10:25, David Gibson wrote:
> On Mon, Sep 30, 2019 at 08:11:56AM +0200, Cédric Le Goater wrote:
>> On 27/09/2019 07:50, David Gibson wrote:
>>> It turns out that all the logic in the SpaprIrq::reset hooks (and some in
>>> the SpaprIrq::post_load hooks) isn't really related to resetting
On Mon, Sep 30, 2019 at 08:11:56AM +0200, Cédric Le Goater wrote:
> On 27/09/2019 07:50, David Gibson wrote:
> > It turns out that all the logic in the SpaprIrq::reset hooks (and some in
> > the SpaprIrq::post_load hooks) isn't really related to resetting the irq
> > backend (that's handled by the
On 27/09/2019 07:50, David Gibson wrote:
> It turns out that all the logic in the SpaprIrq::reset hooks (and some in
> the SpaprIrq::post_load hooks) isn't really related to resetting the irq
> backend (that's handled by the backends' own reset routines). Rather its
> about getting the backend rea
It turns out that all the logic in the SpaprIrq::reset hooks (and some in
the SpaprIrq::post_load hooks) isn't really related to resetting the irq
backend (that's handled by the backends' own reset routines). Rather its
about getting the backend ready to be the active interrupt controller or
stopp
