On Tue, 20 Jun 2017 14:24:08 -0500
Michael Roth wrote:
> Quoting Greg Kurz (2017-06-20 11:51:45)
> > On Tue, 20 Jun 2017 09:53:30 +0800
> > David Gibson wrote:
> >
> > > At the moment, spapr_drc_release() has an ugly switch on the DRC type to
> > > call the right, device-specific release func
On Tue, Jun 20, 2017 at 02:24:08PM -0500, Michael Roth wrote:
> Quoting Greg Kurz (2017-06-20 11:51:45)
> > On Tue, 20 Jun 2017 09:53:30 +0800
> > David Gibson wrote:
> >
> > > At the moment, spapr_drc_release() has an ugly switch on the DRC type to
> > > call the right, device-specific release f
Quoting Greg Kurz (2017-06-20 11:51:45)
> On Tue, 20 Jun 2017 09:53:30 +0800
> David Gibson wrote:
>
> > At the moment, spapr_drc_release() has an ugly switch on the DRC type to
> > call the right, device-specific release function. This cleans it up by
> > doing that via a proper QOM method.
> >
On Tue, 20 Jun 2017 09:53:30 +0800
David Gibson wrote:
> At the moment, spapr_drc_release() has an ugly switch on the DRC type to
> call the right, device-specific release function. This cleans it up by
> doing that via a proper QOM method.
>
> It's still arguably an abstraction violation for t
At the moment, spapr_drc_release() has an ugly switch on the DRC type to
call the right, device-specific release function. This cleans it up by
doing that via a proper QOM method.
It's still arguably an abstraction violation for the DRC code to call into
the specific device code, but one mess at
