On Thu, Jun 18, 2020 at 8:42 PM Thomas Gleixner wrote:
> David Heidelberg writes:
> > is there chance to get this patch included or could be this issue
> > solved with different approach?
>
> Included into what? This patch is incorrect as I pointed out in review
> here:
>
>
> https://lore.kern
David Heidelberg writes:
> is there chance to get this patch included or could be this issue
> solved with different approach?
Included into what? This patch is incorrect as I pointed out in review
here:
https://lore.kernel.org/lkml/alpine.deb.2.21.1812071143480.14...@nanos.tec.linutronix.de
On Mon, Jun 15, 2020 at 10:23:53PM +0200, David Heidelberg wrote:
> Hello,
>
> is there chance to get this patch included
What patch?
Included where?
> or could be this issue solved
> with different approach?
Such as what?
Totally confused,
greg k-h
Hello,
is there chance to get this patch included or could be this issue
solved with different approach?
Actually this patch solve issue on two APQ8064 devices:
* Nexus 7 2013
Tested-by: David Heidelberg
* Nexus 4
Tested-by: Iskren Chernev
Best regards
David Heidelberg
Linus,
On Fri, 7 Dec 2018, Linus Walleij wrote:
> On Fri, Dec 7, 2018 at 12:52 PM Thomas Gleixner wrote:
> > Needs more thought. Btw, the uninstall path does not invoke irq_deactive()
> > either I so hate that chained handler mess
>
> I think it is just extremely uncommon to remove a cha
On Fri, Dec 7, 2018 at 12:52 PM Thomas Gleixner wrote:
> > > This irqchip is in drivers/pinctrl/qcom/pinctrl-msm.c and known
> > > as TLMM.
>
> TLMM == Totally Lost Manufacturer Mess?
It's pretty OK for the most part actually.
> You cannot invoke those callbacks from __irq_do_set_handler() as t
On Fri, 7 Dec 2018, Linus Walleij wrote:
Sorry for answering late.
> On Thu, Nov 29, 2018 at 2:31 PM Linus Walleij
> wrote:
> >
> > This irqchip is in drivers/pinctrl/qcom/pinctrl-msm.c and known
> > as TLMM.
TLMM == Totally Lost Manufacturer Mess?
> > However, the irqchip core helpers in GPI
On Thu, Nov 29, 2018 at 2:31 PM Linus Walleij wrote:
> This addresses a bug in the irqchip core that was triggered
> by new code assuming a strict semantic order of the irqchip
> calls:
>
> .irq_request_resources()
> .irq_enable()
> .irq_disable()
> .irq_release_resources()
>
> Mostly this is
This addresses a bug in the irqchip core that was triggered
by new code assuming a strict semantic order of the irqchip
calls:
.irq_request_resources()
.irq_enable()
.irq_disable()
.irq_release_resources()
Mostly this is working fine when handled inside manage.c,
the calls are strictly happen
9 matches
Mail list logo
