On Fri, 12 Apr 2024 at 14:38, Edgar E. Iglesias
wrote:
>
> On Fri, Apr 12, 2024 at 3:05 PM Peter Maydell
> wrote:
> >
> > On Thu, 11 Apr 2024 at 18:23, Philippe Mathieu-Daudé
> > wrote:
> > >
> > > On 11/4/24 15:43, Peter Maydell wrote:
> > > > On Wed, 21 Aug 2019 at 17:34, Damien Hedde
> >
On Fri, Apr 12, 2024 at 3:05 PM Peter Maydell wrote:
>
> On Thu, 11 Apr 2024 at 18:23, Philippe Mathieu-Daudé
> wrote:
> >
> > On 11/4/24 15:43, Peter Maydell wrote:
> > > On Wed, 21 Aug 2019 at 17:34, Damien Hedde
> > > wrote:
> > >>
> > >> This commit defines an interface allowing
On Thu, 11 Apr 2024 at 18:23, Philippe Mathieu-Daudé wrote:
>
> On 11/4/24 15:43, Peter Maydell wrote:
> > On Wed, 21 Aug 2019 at 17:34, Damien Hedde
> > wrote:
> >>
> >> This commit defines an interface allowing multi-phase reset. This aims
> >> to solve a problem of the actual single-phase
On 11/4/24 15:43, Peter Maydell wrote:
On Wed, 21 Aug 2019 at 17:34, Damien Hedde wrote:
This commit defines an interface allowing multi-phase reset. This aims
to solve a problem of the actual single-phase reset (built in
DeviceClass and BusClass): reset behavior is dependent on the order
in
On Wed, 21 Aug 2019 at 17:34, Damien Hedde wrote:
>
> This commit defines an interface allowing multi-phase reset. This aims
> to solve a problem of the actual single-phase reset (built in
> DeviceClass and BusClass): reset behavior is dependent on the order
> in which reset handlers are called.
On 9/27/19 3:07 PM, Peter Maydell wrote:
> On Tue, 24 Sep 2019 at 12:21, Damien Hedde wrote:
>
> My takes:
> * I think we should keep the reset type. Among other things,
>we probably want a reset type for "PCI bus reset" and
>"SCSI bus reset", when we come to conversion of those
> * I
On Tue, 24 Sep 2019 at 12:21, Damien Hedde wrote:
>
> Hi All,
>
> Do you think I should respin with the sugestions made by David so far ?
>
> + reset type removal
> + s/init/enter/ for the phases terminology
> + handling of parent changes during reset
My takes:
* I think we should keep the
Hi All,
Do you think I should respin with the sugestions made by David so far ?
+ reset type removal
+ s/init/enter/ for the phases terminology
+ handling of parent changes during reset
On 9/18/19 11:11 AM, David Gibson wrote:
> On Wed, Sep 11, 2019 at 04:56:13PM +0200, Damien Hedde wrote:
>>
On Wed, Sep 11, 2019 at 04:56:13PM +0200, Damien Hedde wrote:
>
>
> On 9/11/19 10:06 AM, David Gibson wrote:
> > On Wed, Aug 21, 2019 at 06:33:33PM +0200, Damien Hedde wrote:
> >> This commit defines an interface allowing multi-phase reset. This aims
> >> to solve a problem of the actual
On 9/11/19 10:06 AM, David Gibson wrote:
> On Wed, Aug 21, 2019 at 06:33:33PM +0200, Damien Hedde wrote:
>> This commit defines an interface allowing multi-phase reset. This aims
>> to solve a problem of the actual single-phase reset (built in
>> DeviceClass and BusClass): reset behavior is
On Wed, Aug 21, 2019 at 06:33:33PM +0200, Damien Hedde wrote:
> This commit defines an interface allowing multi-phase reset. This aims
> to solve a problem of the actual single-phase reset (built in
> DeviceClass and BusClass): reset behavior is dependent on the order
> in which reset handlers are
This commit defines an interface allowing multi-phase reset. This aims
to solve a problem of the actual single-phase reset (built in
DeviceClass and BusClass): reset behavior is dependent on the order
in which reset handlers are called. In particular doing external
side-effect (like setting an
12 matches
Mail list logo
