On Wed, Apr 10, 2019 at 7:44 AM Brian Norris wrote:
>
> I think our key difference here is in how much we trust the device:
> knowing the quality of the firmware running on some of these devices,
> I wouldn't totally trust that they get it right.
No.
You claim that IRQ_NOAUTOEN makes any
On Tue, Apr 9, 2019 at 8:43 PM Linus Torvalds
wrote:
> Either it's edge-triggered and you'll get one possibly spurious
> interrupt for an old issue, or it's level-triggered and setting up the
> hw should bring the irq line inactive and you'll be ok.
I think our key difference here is in how much
On Tue, Apr 9, 2019 at 5:26 PM Brian Norris wrote:
>
> So, I think the problem is still potentially present no matter when we
> request the IRQ. The "uninitialized" state of the hardware (or,
> firmware) just exposes the issue extremely clearly.
Well, I think that as long as you don't request
Hi Linus,
Thanks for the reply! It's amusing that you're the only one (well,
besides the gentleman who sits a few feet from me and kindly provided
his Reviewed-by) to review my patch.
On Tue, Apr 9, 2019 at 7:20 PM Linus Torvalds
wrote:
> On Tue, Apr 9, 2019 at 8:49 AM Brian Norris wrote:
> >
On Tue, Apr 9, 2019 at 8:49 AM Brian Norris wrote:
>
> Badly-designed systems might have (for example) active-high wake pins
> that default to high (e.g., because of external pull ups) until they
> have an active firmware which starts driving it low. This can cause an
> interrupt storm in the
Badly-designed systems might have (for example) active-high wake pins
that default to high (e.g., because of external pull ups) until they
have an active firmware which starts driving it low. This can cause an
interrupt storm in the time between request_irq() and disable_irq().
We don't support
6 matches
Mail list logo
