linux-kernel - Re: [PATCH] regmap: irq: fix ack-invert

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ+vNU2d-KKMHvb2bJt-b_9h7c2YM1NJS4PYYi7Y=YzT-VQJNg@mail.gmail.com>
Date:   Wed, 28 Feb 2018 13:17:39 -0800
From:   Tim Harvey <tharvey@...eworks.com>
To:     Tony Lindgren <tony@...mide.com>, Guo Zeng <Guo.Zeng@....com>,
        Barry Song <Baohua.Song@....com>,
        Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Sebastian Reichel <sebastian.reichel@...labora.co.uk>
Subject: Re: [PATCH] regmap: irq: fix ack-invert

On Tue, Feb 27, 2018 at 10:39 AM, Tony Lindgren <tony@...mide.com> wrote:
> * Tim Harvey <tharvey@...eworks.com> [180227 16:07]:
>> When acking irqs we need to take into account the ack-invert case. Without
>> this chips that require 0's to ACK interrupts will never clear the interrupt.
>>
>> I am working on an mfd driver that will use ack-invert and discovered
>> this issue. The only user of ack_invert currently appears to be the
>> motorola-cpcap driver. I'm not clear why that driver doesn't appear affected
>> so I'm cc'ing those involved with that driver for review and testing.
>
> I gave this a quick try and it fails with cpcap. So yeah, you're right,
> it seems we still have the cpcap config wrong.
>

Tony,

So you would agree with my findings/patch right? I certainly don't
want to break regmap-irq in general :)

Adding Guo Zeng and Barry Song to the thread as they were the authors
of the ack_invert feature (a650fdd9427f1f5236f83d2d8137bea9b452fa53)
and I'm not clear what happened to the chip they were needing it for.

> Things do work with the following patch and your patch for cpcap. So
> they should both be applied together as a single patch.
>
> Care to fold in the following change and then repost your patch?
>
> Otherwise we might end up breaking things easily for booting or
> bisect or stable. Or else the patch below needs to be applied first
> to avoid breaking things.
>

So cpcap needs to write 1's to clear irq's not 0's right?

Yes, I can certainly roll in the fix for cpcap if everyone agrees
that's the right move.

I'll wait for some feedback from Mark Brown as well.

Regards,

Tim