On Mon, Jul 01, 2024 at 04:13:00AM -0500, Hari Nagalla wrote:
> On 6/28/24 14:58, Mathieu Poirier wrote:
> > > This could lead in an incorrect IPC-only mode detection if reset line is
> > > asserted (so reset_control_status() return > 0) and c_state != 0 and
> > > halted == 0.
> > > In this case,
On 6/28/24 14:58, Mathieu Poirier wrote:
This could lead in an incorrect IPC-only mode detection if reset line is
asserted (so reset_control_status() return > 0) and c_state != 0 and
halted == 0.
In this case, the old code would have detected an IPC-only mode instead
of a mismatched mode.
Your
Nishanth, Vignesh, Hari and Andrew - please have a look at this patch.
Thanks,
Mathieu
On Fri, 28 Jun 2024 at 13:53, Mathieu Poirier
wrote:
>
> Good day,
>
> On Fri, Jun 21, 2024 at 05:00:55PM +0200, Richard Genoud wrote:
> > ret variable was used to test reset status, get from
> >
Good day,
On Fri, Jun 21, 2024 at 05:00:55PM +0200, Richard Genoud wrote:
> ret variable was used to test reset status, get from
> reset_control_status() call. But this variable was overwritten by
> ti_sci_proc_get_status() a few lines bellow.
> And as ti_sci_proc_get_status() returns 0 or a
ret variable was used to test reset status, get from
reset_control_status() call. But this variable was overwritten by
ti_sci_proc_get_status() a few lines bellow.
And as ti_sci_proc_get_status() returns 0 or a negative value (in this
latter case, followed by a return), the expression !ret was
5 matches
Mail list logo
