> My hunch is the second hunk of the original patch will fix this.
O.K.
But please fully explain how the race happens and how the fix fully
fixes it. I don't really want to add code which just makes the race
window smaller, but the race still happens. That helps nobody.
In the end, i think you w
On 2019-02-04 9:21 p.m., Andrew Lunn wrote:
>> The problem is INTn can go low before the interrupt handler for it is
>> registered and enabled.
>> This can't happen. The domain is setup immediately after registering
>> the GPIO interrupt.
>> The interrupt can't fire until one of the enables is set
Something is really wrong with how your patches are submitted.
The patch shows up in between the commit message and your signoff
tags, also the patch appears to be mangled by your email client.
Please fix this before submitting any future work.
Thank you.
> The problem is INTn can go low before the interrupt handler for it is
> registered and enabled.
> This can't happen. The domain is setup immediately after registering
> the GPIO interrupt.
> The interrupt can't fire until one of the enables is set.
These two statement seem to contradict each o
On 2019-02-04 6:14 p.m., Andrew Lunn wrote:
> On Mon, Feb 04, 2019 at 04:59:13PM -0500, John David Anglin wrote:
>> This change fixes a race condition in the setup of hardware irqs and the
>> code enabling PHY link detection in the mv88e6xxx driver.
>>
>> This race was observed on the espressobin b
On Mon, Feb 04, 2019 at 04:59:13PM -0500, John David Anglin wrote:
> This change fixes a race condition in the setup of hardware irqs and the
> code enabling PHY link detection in the mv88e6xxx driver.
>
> This race was observed on the espressobin board where the GPIO interrupt
> controller only s
This change fixes a race condition in the setup of hardware irqs and the
code enabling PHY link detection in the mv88e6xxx driver.
This race was observed on the espressobin board where the GPIO interrupt
controller only supports edge interrupts. If the INTn output pin goes low
before the GPIO int
