Hi,
On 22/05/17 18:15, Julien Grall wrote:
>
>
> On 22/05/17 17:49, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 12/05/17 15:19, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 11/05/17 18:53, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
>>>
On 22/05/17 17:49, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/05/17 15:19, Julien Grall wrote:
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at
Hi,
On 12/05/17 15:19, Julien Grall wrote:
> Hi Andre,
>
> On 11/05/17 18:53, Andre Przywara wrote:
>> For LPIs the struct pending_irq's are dynamically allocated and the
>> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
>> at any time, teach the VGIC how to deal with irq
On Thu, 11 May 2017, Andre Przywara wrote:
> For LPIs the struct pending_irq's are dynamically allocated and the
> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
> at any time, teach the VGIC how to deal with irq_to_pending() returning
> a NULL pointer.
> We just do nothing
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothin
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothing in this case or clean up the LR if the virtual LPI
n
