On Tue, Jun 29, 2021 at 01:50:09PM +0100, Valentin Schneider wrote:
quoted
Now that the proper infrastructure is in place, convert the irq-gic chip to
use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.
For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOI write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.
The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.
EOImode=0 handling remains unchanged.
Signed-off-by: Valentin Schneider <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210629125010.458872-13-valentin.schneider@arm.com
---
This patch results in a variety of crashes in -next.
Passing the stacktrace through scripts/decode_stracktrace.sh would help by
giving line numbers - that said I'm pretty sure this is caused by the
flow-handler now issuing a chip->irq_ack(), and this has an irqchip that
doesn't have one.
The hardware name points me at arch/arm/mach-imx/mach-imx6ul.c, but I can't
figure out an actual devicetree/irqchip layout from this.
Ah, with some more grepping I did find arch/arm/mach-imx/gpc.c, and bingo,
no .irq_ack().
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation. I'm tempted to apply a dumb
.irq_ack = irq_chip_ack_parent
to all irqchips without one specified. Let's see how bad this gets, does
the below help?
---
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation.
The ones in arch/arm are easy enough to catch (I see gpc, omap-wakeupgen
and some exynos suspend thing), less so for the ones in drivers/irqchip...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Jun 29, 2021 at 01:50:09PM +0100, Valentin Schneider wrote:
quoted
Now that the proper infrastructure is in place, convert the irq-gic chip to
use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.
For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOI write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.
The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.
EOImode=0 handling remains unchanged.
Signed-off-by: Valentin Schneider <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210629125010.458872-13-valentin.schneider@arm.com
---
This patch results in a variety of crashes in -next.
Passing the stacktrace through scripts/decode_stracktrace.sh would help by
giving line numbers - that said I'm pretty sure this is caused by the
flow-handler now issuing a chip->irq_ack(), and this has an irqchip that
doesn't have one.
The hardware name points me at arch/arm/mach-imx/mach-imx6ul.c, but I can't
figure out an actual devicetree/irqchip layout from this.
This one was imx6ul-14x14-evk, and I had seen a similar crash with mcimx7d-sabre
and imx7d-sdb.
Ah, with some more grepping I did find arch/arm/mach-imx/gpc.c, and bingo,
no .irq_ack().
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation. I'm tempted to apply a dumb
.irq_ack = irq_chip_ack_parent
to all irqchips without one specified. Let's see how bad this gets, does
the below help?
Yes, it does, for both mcimx7d-sabre and mcimx6ul-evk bot tests with qemu.
That makes me wonder - would it make sense to (also) change the calling
code to check if irq_ack is NULL, and call irq_chip_ack_parent if it is ?
Thanks,
Guenter
On Tue, Jun 29, 2021 at 01:50:09PM +0100, Valentin Schneider wrote:
quoted
Now that the proper infrastructure is in place, convert the irq-gic chip to
use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.
For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOI write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.
The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.
EOImode=0 handling remains unchanged.
Signed-off-by: Valentin Schneider <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210629125010.458872-13-valentin.schneider@arm.com
---
This patch results in a variety of crashes in -next.
Passing the stacktrace through scripts/decode_stracktrace.sh would help by
giving line numbers - that said I'm pretty sure this is caused by the
flow-handler now issuing a chip->irq_ack(), and this has an irqchip that
doesn't have one.
The hardware name points me at arch/arm/mach-imx/mach-imx6ul.c, but I can't
figure out an actual devicetree/irqchip layout from this.
Ah, with some more grepping I did find arch/arm/mach-imx/gpc.c, and bingo,
no .irq_ack().
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation. I'm tempted to apply a dumb
.irq_ack = irq_chip_ack_parent
to all irqchips without one specified. Let's see how bad this gets, does
the below help?
As a follow-up, Coccinelle tells me that there are more than 300 declarations of
struct irq_chip variables without irq_ack pointer in the kernel. Does this problem
affect all of them or just a subset ? If it doesn't affect all of them, how does
one know when irq_ack is mandatory and when not ?
Thanks,
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Aug 14, 2021 at 11:31:45PM +0100, Valentin Schneider wrote:
On 14/08/21 23:26, Valentin Schneider wrote:
quoted
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation.
The ones in arch/arm are easy enough to catch (I see gpc, omap-wakeupgen
and some exynos suspend thing), less so for the ones in drivers/irqchip...
Try:
make coccicheck COCCI=irq_chip.cocci MODE=report M=.
with the script below. I am sure the script could be augmented if
there is some secondary condition that makes irq_ack mandatory.
Guenter
---
irq_chip.cocci:
virtual report
@c@
identifier chip;
position p;
@@
struct irq_chip chip@p = {
...
};
@i@
identifier c.chip;
identifier f;
@@
struct irq_chip chip = {
.irq_ack = f,
};
@script:python depends on c && !i && report@
p << c.p;
@@
print "Found %s:%s" % (p[0].file, p[0].line)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-15 06:54:13
On Sat, 14 Aug 2021 23:26:07 +0100,
Valentin Schneider [off-list ref] wrote:
Hi,
On 14/08/21 12:47, Guenter Roeck wrote:
quoted
On Tue, Jun 29, 2021 at 01:50:09PM +0100, Valentin Schneider wrote:
quoted
Now that the proper infrastructure is in place, convert the irq-gic chip to
use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.
For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOI write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.
The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.
EOImode=0 handling remains unchanged.
Signed-off-by: Valentin Schneider <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210629125010.458872-13-valentin.schneider@arm.com
---
This patch results in a variety of crashes in -next.
Passing the stacktrace through scripts/decode_stracktrace.sh would help by
giving line numbers - that said I'm pretty sure this is caused by the
flow-handler now issuing a chip->irq_ack(), and this has an irqchip that
doesn't have one.
The hardware name points me at arch/arm/mach-imx/mach-imx6ul.c, but I can't
figure out an actual devicetree/irqchip layout from this.
Ah, with some more grepping I did find arch/arm/mach-imx/gpc.c, and bingo,
no .irq_ack().
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation. I'm tempted to apply a dumb
.irq_ack = irq_chip_ack_parent
to all irqchips without one specified. Let's see how bad this gets, does
the below help?
You need to be selective. A number of irqchips don't need an irq_ack
callback.
This is going and-up in a wack-a-mole game. There is probably a bunch
of these all over the place. I'd rather squash it at the root,
i.e. with something like this (untested):
We probably need something similar for irq_eoi().
This however shows a more fundamental problem, I'm afraid. We set
IRQCHIP_AUTOMASKS_FLOW in the GIC drivers (i.e. at the root), but test
for it at the top of the hierarchy. As soon as we have more than a
single layer of irqchip, this will do the wrong thing (or at least
miss the masking optimisation).
This probably advocates for moving the flag into the descriptor. This
really makes sense, as the flow is global to the whole stack, not just
to the localised irqchip.
In order to restore -next into a working state, I'm temporarily
dropping this series. Hopefully, we can sort this out before the merge
window and reinstate it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-15 07:01:28
On Sun, 15 Aug 2021 00:36:39 +0100,
Guenter Roeck [off-list ref] wrote:
On 8/14/21 3:26 PM, Valentin Schneider wrote:
quoted
Hi,
On 14/08/21 12:47, Guenter Roeck wrote:
quoted
On Tue, Jun 29, 2021 at 01:50:09PM +0100, Valentin Schneider wrote:
quoted
Now that the proper infrastructure is in place, convert the irq-gic chip to
use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.
For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOI write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.
The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.
EOImode=0 handling remains unchanged.
Signed-off-by: Valentin Schneider <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210629125010.458872-13-valentin.schneider@arm.com
---
This patch results in a variety of crashes in -next.
Passing the stacktrace through scripts/decode_stracktrace.sh would help by
giving line numbers - that said I'm pretty sure this is caused by the
flow-handler now issuing a chip->irq_ack(), and this has an irqchip that
doesn't have one.
The hardware name points me at arch/arm/mach-imx/mach-imx6ul.c, but I can't
figure out an actual devicetree/irqchip layout from this.
Ah, with some more grepping I did find arch/arm/mach-imx/gpc.c, and bingo,
no .irq_ack().
Now, the above makes me feel like this is the start of a wild goose chase
for irqchips in a similar situation. I'm tempted to apply a dumb
.irq_ack = irq_chip_ack_parent
to all irqchips without one specified. Let's see how bad this gets, does
the below help?
As a follow-up, Coccinelle tells me that there are more than 300
declarations of struct irq_chip variables without irq_ack pointer in
the kernel. Does this problem affect all of them or just a subset ?
If it doesn't affect all of them, how does one know when irq_ack is
mandatory and when not ?
One needs to understand what flow is being used. For irqchip stacks
using fast-eoi, there was no need for an irq_ack callback until we
switched to Valentin's "strict" flow.
The problem is that although irqchip *look* like they can be composed
at will, the composition only makes sense if they all agree on the
flow that is being used.
So we can either identify the irqchips that need to be updated (not an
easy task, but not impossible: just look for anything that feeds into
a GIC through a hierarchy and not a mux). Or we can make the flow
iterate over the irqchip layers.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This is going and-up in a wack-a-mole game. There is probably a bunch
of these all over the place. I'd rather squash it at the root,
i.e. with something like this (untested):
We probably need something similar for irq_eoi().
This however shows a more fundamental problem, I'm afraid. We set
IRQCHIP_AUTOMASKS_FLOW in the GIC drivers (i.e. at the root), but test
for it at the top of the hierarchy. As soon as we have more than a
single layer of irqchip, this will do the wrong thing (or at least
miss the masking optimisation).
Yup.
This probably advocates for moving the flag into the descriptor. This
really makes sense, as the flow is global to the whole stack, not just
to the localised irqchip.
Are we guaranteed to have
.irq_ack \in {NULL, irq_chip_ack_parent}
for all intermediate (!root) irqchips? I don't see why that wouldn't be the
case, and with that in mind what you described makes sense to me.
In order to restore -next into a working state, I'm temporarily
dropping this series. Hopefully, we can sort this out before the merge
window and reinstate it.
I'm away from any keyboard for most of this week, but I'll get to it by the
weekend.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-18 16:58:26
On Tue, 17 Aug 2021 01:30:43 +0100,
Valentin Schneider [off-list ref] wrote:
On 15/08/21 07:54, Marc Zyngier wrote:
quoted
This is going and-up in a wack-a-mole game. There is probably a bunch
of these all over the place. I'd rather squash it at the root,
i.e. with something like this (untested):
We probably need something similar for irq_eoi().
This however shows a more fundamental problem, I'm afraid. We set
IRQCHIP_AUTOMASKS_FLOW in the GIC drivers (i.e. at the root), but test
for it at the top of the hierarchy. As soon as we have more than a
single layer of irqchip, this will do the wrong thing (or at least
miss the masking optimisation).
Yup.
quoted
This probably advocates for moving the flag into the descriptor. This
really makes sense, as the flow is global to the whole stack, not just
to the localised irqchip.
Are we guaranteed to have
.irq_ack \in {NULL, irq_chip_ack_parent}
for all intermediate (!root) irqchips? I don't see why that wouldn't
be the case, and with that in mind what you described makes sense to
me.
An intermediate layer is allowed to implement its own irq_ack that is
not irq_chip_ack_parent, but it then has to call irq_chip_ack_parent
itself.
There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
the irqchip flow to use either handle_fasteoi_ack_irq or
handle_fasteoi_mask_irq, which won't play very nicely with this.
Someone said Cavium?
quoted
In order to restore -next into a working state, I'm temporarily
dropping this series. Hopefully, we can sort this out before the merge
window and reinstate it.
I'm away from any keyboard for most of this week, but I'll get to it by the
weekend.
No worries, enjoy your break!
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, 17 Aug 2021 01:30:43 +0100,
Valentin Schneider [off-list ref] wrote:
quoted
Are we guaranteed to have
.irq_ack \in {NULL, irq_chip_ack_parent}
for all intermediate (!root) irqchips? I don't see why that wouldn't
be the case, and with that in mind what you described makes sense to
me.
An intermediate layer is allowed to implement its own irq_ack that is
not irq_chip_ack_parent, but it then has to call irq_chip_ack_parent
itself.
Right, makes sense.
There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
the irqchip flow to use either handle_fasteoi_ack_irq or
handle_fasteoi_mask_irq, which won't play very nicely with this.
Someone said Cavium?
Humph...
I'm not familiar at all with the gpiolib irqchips, but I was under the
impression those would involve chained IRQs (it does appear to be the case
for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled
via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever
flow was installed by the relevant driver.
I can't easily grok what goes on between that gpio-thunderx.c driver and
gpiolib, but since that GPIO chip has
.irq_eoi = irq_chip_eoi_parent,
and
girq->parent_domain =
irq_get_irq_data(txgpio->msix_entries[0].vector)->domain;
(GPIOs hooked to MSI-X? Do I want to know?)
I'm guessing it is *not* chained, which means the irq_set_handler_locked()
affects the entire stack :/
[!!!] Speaking of chained IRQs, I'm now thinking this series breaks them;
chained_irq_enter() + chained_irq_exit() will only issue an ->irq_eoi(),
skipping the ->irq_ack()... One more thing to add to the list!
quoted
quoted
In order to restore -next into a working state, I'm temporarily
dropping this series. Hopefully, we can sort this out before the merge
window and reinstate it.
I'm away from any keyboard for most of this week, but I'll get to it by the
weekend.
No worries, enjoy your break!
I sure did, Thanks!
M.
--
Without deviation from the norm, progress is not possible.
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-23 09:33:51
On Sun, 22 Aug 2021 23:16:10 +0100,
Valentin Schneider [off-list ref] wrote:
On 18/08/21 17:58, Marc Zyngier wrote:
quoted
On Tue, 17 Aug 2021 01:30:43 +0100,
Valentin Schneider [off-list ref] wrote:
quoted
Are we guaranteed to have
.irq_ack \in {NULL, irq_chip_ack_parent}
for all intermediate (!root) irqchips? I don't see why that wouldn't
be the case, and with that in mind what you described makes sense to
me.
An intermediate layer is allowed to implement its own irq_ack that is
not irq_chip_ack_parent, but it then has to call irq_chip_ack_parent
itself.
Right, makes sense.
quoted
There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
the irqchip flow to use either handle_fasteoi_ack_irq or
handle_fasteoi_mask_irq, which won't play very nicely with this.
Someone said Cavium?
Humph...
I'm not familiar at all with the gpiolib irqchips, but I was under the
impression those would involve chained IRQs (it does appear to be the case
for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled
via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever
flow was installed by the relevant driver.
Not all of them are built like this. There is actually a bunch of
these build as full hierarchies (QC, nvidia and some others).
I can't easily grok what goes on between that gpio-thunderx.c driver and
gpiolib, but since that GPIO chip has
.irq_eoi = irq_chip_eoi_parent,
and
girq->parent_domain =
irq_get_irq_data(txgpio->msix_entries[0].vector)->domain;
(GPIOs hooked to MSI-X? Do I want to know?)
It's good, isn't it? TX1 has all its HW appearing as PCI, even if it
clearly isn't PCI underneath.
I'm guessing it is *not* chained, which means the irq_set_handler_locked()
affects the entire stack :/
It does. We can probably fix that, but I won't be able to test (my TX1
was taken away a few months ago...). I'll accept body donations, for
scientific purposes.
[!!!] Speaking of chained IRQs, I'm now thinking this series breaks them;
chained_irq_enter() + chained_irq_exit() will only issue an ->irq_eoi(),
skipping the ->irq_ack()... One more thing to add to the list!
Urghh... Yeah, that's awful.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sun, 22 Aug 2021 23:16:10 +0100,
Valentin Schneider [off-list ref] wrote:
quoted
On 18/08/21 17:58, Marc Zyngier wrote:
quoted
There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
the irqchip flow to use either handle_fasteoi_ack_irq or
handle_fasteoi_mask_irq, which won't play very nicely with this.
Someone said Cavium?
Humph...
I'm not familiar at all with the gpiolib irqchips, but I was under the
impression those would involve chained IRQs (it does appear to be the case
for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled
via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever
flow was installed by the relevant driver.
Not all of them are built like this. There is actually a bunch of
these build as full hierarchies (QC, nvidia and some others).
I see, thanks!
quoted
I can't easily grok what goes on between that gpio-thunderx.c driver and
gpiolib, but since that GPIO chip has
.irq_eoi = irq_chip_eoi_parent,
and
girq->parent_domain =
irq_get_irq_data(txgpio->msix_entries[0].vector)->domain;
(GPIOs hooked to MSI-X? Do I want to know?)
It's good, isn't it? TX1 has all its HW appearing as PCI, even if it
clearly isn't PCI underneath.
quoted
I'm guessing it is *not* chained, which means the irq_set_handler_locked()
affects the entire stack :/
It does. We can probably fix that, but I won't be able to test (my TX1
was taken away a few months ago...). I'll accept body donations, for
scientific purposes.
Looks like there are still some over on s/packet/equinix/, so I should be
able to poke at one.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-23 12:17:09
On Mon, 23 Aug 2021 11:38:58 +0100,
Valentin Schneider [off-list ref] wrote:
On 23/08/21 10:33, Marc Zyngier wrote:
quoted
On Sun, 22 Aug 2021 23:16:10 +0100,
Valentin Schneider [off-list ref] wrote:
quoted
On 18/08/21 17:58, Marc Zyngier wrote:
quoted
There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
the irqchip flow to use either handle_fasteoi_ack_irq or
handle_fasteoi_mask_irq, which won't play very nicely with this.
Someone said Cavium?
Humph...
I'm not familiar at all with the gpiolib irqchips, but I was under the
impression those would involve chained IRQs (it does appear to be the case
for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled
via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever
flow was installed by the relevant driver.
Not all of them are built like this. There is actually a bunch of
these build as full hierarchies (QC, nvidia and some others).
I see, thanks!
quoted
quoted
I can't easily grok what goes on between that gpio-thunderx.c driver and
gpiolib, but since that GPIO chip has
.irq_eoi = irq_chip_eoi_parent,
and
girq->parent_domain =
irq_get_irq_data(txgpio->msix_entries[0].vector)->domain;
(GPIOs hooked to MSI-X? Do I want to know?)
It's good, isn't it? TX1 has all its HW appearing as PCI, even if it
clearly isn't PCI underneath.
quoted
I'm guessing it is *not* chained, which means the irq_set_handler_locked()
affects the entire stack :/
It does. We can probably fix that, but I won't be able to test (my TX1
was taken away a few months ago...). I'll accept body donations, for
scientific purposes.
Looks like there are still some over on s/packet/equinix/, so I should be
able to poke at one.
That's where mine used to live, but the WoA people decided that I
really didn't need one, and I'm now only allowed to borrow one of the
old eMAGs. If you can pull strings, let me know! :D
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
In order to restore -next into a working state, I'm temporarily
dropping this series. Hopefully, we can sort this out before the merge
window and reinstate it.
So what I thought would be a small weekend job turned to be a bit more
involved...
- The throughput improvement with v4 is half of what it was on v3. I
rebased v3 on the last tip/irq/core and this also took a hit, I'm digging
into it.
- TX1 is being an absolute PITA to work with, I can't seem to boot anything
else than the distro kernel ATM (grub commits seppuku).
- Last but not least, I'll soon be AWOL for 3 weeks, a good chunk of it
involving sitting atop a mountain without electricity. So even if I can
magically fix all of the above say tomorrow, I'd rather be available to
~watch~ handle any unforeseen fireworks.
Hopefully I'll catch the next revision :)
Thanks,
M.
--
Without deviation from the norm, progress is not possible.