On Tue, 02 Apr 2019 15:43:31 +0100,
Heyi Guo wrote:
>
> Hi Marc,
>
> The issue has been fixed after applying your patch.
Excellent, thanks for testing it. I've now applied the final patch to
the 5.1-fixes branch to get a bit more exposure before merging it to
master.
M.
>
> Thanks,
Hi Marc,
The issue has been fixed after applying your patch.
Thanks,
Heyi
On 2019/4/2 17:32, Heyi Guo wrote:
Thanks, I'll use this one for test.
Heyi
On 2019/4/2 16:48, Marc Zyngier wrote:
On Tue, 02 Apr 2019 09:22:29 +0100,
Auger Eric wrote:
Hi Marc,
On 4/2/19 9:24 AM, Marc Zyngier
Hi Marc,
On 4/2/19 10:48 AM, Marc Zyngier wrote:
> On Tue, 02 Apr 2019 09:22:29 +0100,
> Auger Eric wrote:
>>
>> Hi Marc,
>>
>> On 4/2/19 9:24 AM, Marc Zyngier wrote:
>>> When disabling LPIs (for example on reset) at the redistributor
>>> level, it is expected that LPIs that was pending in the
Thanks, I'll use this one for test.
Heyi
On 2019/4/2 16:48, Marc Zyngier wrote:
On Tue, 02 Apr 2019 09:22:29 +0100,
Auger Eric wrote:
Hi Marc,
On 4/2/19 9:24 AM, Marc Zyngier wrote:
When disabling LPIs (for example on reset) at the redistributor
level, it is expected that LPIs that was
On Tue, 02 Apr 2019 09:22:29 +0100,
Auger Eric wrote:
>
> Hi Marc,
>
> On 4/2/19 9:24 AM, Marc Zyngier wrote:
> > When disabling LPIs (for example on reset) at the redistributor
> > level, it is expected that LPIs that was pending in the CPU
> > interface are eventually retired.
> >
> >
Hi Marc,
On 4/2/19 9:24 AM, Marc Zyngier wrote:
> When disabling LPIs (for example on reset) at the redistributor
> level, it is expected that LPIs that was pending in the CPU
> interface are eventually retired.
>
> Currently, this is not what is happening, and these LPIs will
> stay in the
