[PATCH v2 1/1] pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler

[PATCH v2 1/1] pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler

[Alexander Stein]

According to VLI64 Intel Atom E3800 Specification Update (#329901)
concurrent read accesses may result in returning 0xffffffff and write
accesses may be dropped silently.
To workaround all accesses must be protected by locks.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
I actually had the case where the read access in byt_irq_unmask returned
0xffffffff. After OR'ing the trigger bits and writing 0xffffffff back to
BYT_CONF0_REG things started to act strange.

Changes in v2:
* Adjusted commit message
* Remove locks in initializiation and suspend/resume functions
  namely: byt_gpio_irq_init_hw, byt_gpio_suspend and byt_gpio_resume
* Simply use raw_spin_lock instead of raw_spin_lock_irqsave inside IRQ handler

 drivers/pinctrl/intel/pinctrl-baytrail.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c
index 9a1bbc1..6c7eed8 100644
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -1612,7 +1612,9 @@ static void byt_gpio_irq_handler(struct irq_desc *desc)
 			continue;
 		}
 
+		raw_spin_lock(&vg->lock);
 		pending = readl(reg);
+		raw_spin_unlock(&vg->lock);
 		for_each_set_bit(pin, &pending, 32) {
 			virq = irq_find_mapping(vg->chip.irqdomain, base + pin);
 			generic_handle_irq(virq);
-- 
2.10.2

Re: [PATCH v2 1/1] pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler

[Mika Westerberg]

On Mon, Jan 30, 2017 at 12:35:28PM +0100, Alexander Stein wrote:
> According to VLI64 Intel Atom E3800 Specification Update (#329901)
> concurrent read accesses may result in returning 0xffffffff and write
> accesses may be dropped silently.
> To workaround all accesses must be protected by locks.
> 
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Should probably go to stable as well.

Re: [PATCH v2 1/1] pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler

[Linus Walleij]

On Mon, Jan 30, 2017 at 12:35 PM, Alexander Stein
<alexander.stein@systec-electronic.com> wrote:

> According to VLI64 Intel Atom E3800 Specification Update (#329901)
> concurrent read accesses may result in returning 0xffffffff and write
> accesses may be dropped silently.
> To workaround all accesses must be protected by locks.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>

Patch applied for fixes and tagged for stable with Mika's ACK.

Yours,
Linus Walleij

Re: [PATCH v2 1/1] pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler

[Alexander Stein]

On Monday 30 January 2017 13:51:49, Mika Westerberg wrote:
> On Mon, Jan 30, 2017 at 12:35:28PM +0100, Alexander Stein wrote:
> > According to VLI64 Intel Atom E3800 Specification Update (#329901)
> > concurrent read accesses may result in returning 0xffffffff and write
> > accesses may be dropped silently.
> > To workaround all accesses must be protected by locks.
> > 
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> 
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> 
> Should probably go to stable as well.

Sure, but I don't know which stable kernels this should go in.

Best regards,
Alexander

Re: [PATCH v2 1/1] pinctrl: baytrail: Add missing spinlock usage in byt_gpio_irq_handler

[Linus Walleij]

On Wed, Feb 1, 2017 at 8:47 AM, Alexander Stein
<alexander.stein@systec-electronic.com> wrote:
> On Monday 30 January 2017 13:51:49, Mika Westerberg wrote:
>> On Mon, Jan 30, 2017 at 12:35:28PM +0100, Alexander Stein wrote:
>> > According to VLI64 Intel Atom E3800 Specification Update (#329901)
>> > concurrent read accesses may result in returning 0xffffffff and write
>> > accesses may be dropped silently.
>> > To workaround all accesses must be protected by locks.
>> >
>> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
>>
>> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>>
>> Should probably go to stable as well.
>
> Sure, but I don't know which stable kernels this should go in.

More often than not, I *think* Greg will figure that out by:
"does it apply?" "then yes"

Yours,
Linus Walleij