Searched hist:"6 eb486b6" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/include/linux/irqchip/ |
| H A D | arm-gic-v3.h | 6eb486b6 Wed Mar 21 20:58:49 CDT 2018 Shanker Donthineni <shankerd@codeaurora.org> irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
Booting with GICR_CTLR.EnableLPI=1 is usually a bad idea, and may
result in subtle memory corruption. Detecting this is thus pretty
important.
On detecting that LPIs are still enabled, we taint the kernel (because
we're not sure of anything anymore), and try to disable LPIs. This can
fail, as implementations are allowed to implement GICR_CTLR.EnableLPI
as a one-way enable, meaning the redistributors cannot be reprogrammed
with new tables.
Should this happen, we fail probing the redistributor and warn the user
that things are pretty dire.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
[maz: reworded changelog, minor comment and message changes]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
6eb486b6 Wed Mar 21 20:58:49 CDT 2018 Shanker Donthineni <shankerd@codeaurora.org> irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
Booting with GICR_CTLR.EnableLPI=1 is usually a bad idea, and may
result in subtle memory corruption. Detecting this is thus pretty
important.
On detecting that LPIs are still enabled, we taint the kernel (because
we're not sure of anything anymore), and try to disable LPIs. This can
fail, as implementations are allowed to implement GICR_CTLR.EnableLPI
as a one-way enable, meaning the redistributors cannot be reprogrammed
with new tables.
Should this happen, we fail probing the redistributor and warn the user
that things are pretty dire.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
[maz: reworded changelog, minor comment and message changes]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
| /openbmc/linux/drivers/irqchip/ |
| H A D | irq-gic-v3-its.c | 6eb486b6 Wed Mar 21 20:58:49 CDT 2018 Shanker Donthineni <shankerd@codeaurora.org> irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
Booting with GICR_CTLR.EnableLPI=1 is usually a bad idea, and may
result in subtle memory corruption. Detecting this is thus pretty
important.
On detecting that LPIs are still enabled, we taint the kernel (because
we're not sure of anything anymore), and try to disable LPIs. This can
fail, as implementations are allowed to implement GICR_CTLR.EnableLPI
as a one-way enable, meaning the redistributors cannot be reprogrammed
with new tables.
Should this happen, we fail probing the redistributor and warn the user
that things are pretty dire.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
[maz: reworded changelog, minor comment and message changes]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
6eb486b6 Wed Mar 21 20:58:49 CDT 2018 Shanker Donthineni <shankerd@codeaurora.org> irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
Booting with GICR_CTLR.EnableLPI=1 is usually a bad idea, and may
result in subtle memory corruption. Detecting this is thus pretty
important.
On detecting that LPIs are still enabled, we taint the kernel (because
we're not sure of anything anymore), and try to disable LPIs. This can
fail, as implementations are allowed to implement GICR_CTLR.EnableLPI
as a one-way enable, meaning the redistributors cannot be reprogrammed
with new tables.
Should this happen, we fail probing the redistributor and warn the user
that things are pretty dire.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
[maz: reworded changelog, minor comment and message changes]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|