linux-kernel - Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear

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]

Date:   Sun, 15 Nov 2020 10:43:08 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     Tim Harvey <tharvey@...eworks.com>
Cc:     Lee Jones <lee.jones@...aro.org>,
        open list <linux-kernel@...r.kernel.org>,
        Carl Philipp Klemm <philipp@...s.xyz>,
        Laxminath Kasam <lkasam@...eaurora.org>,
        Merlijn Wajer <merlijn@...zup.org>,
        Mark Brown <broonie@...nel.org>, Pavel Machek <pavel@....cz>,
        Sebastian Reichel <sre@...nel.org>
Subject: Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap
 clear_ack

* Tim Harvey <tharvey@...eworks.com> [201113 22:07]:
> 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
> appears to not only add the new clear_ack case it also attempts to
> resolve the long standing ack_invert issue with this change:
> 
> - ret = regmap_write(map, reg, data->status_buf[i]);
> + if (chip->ack_invert)
> +      ret = regmap_write(map, reg,
> +      ~data->status_buf[i]);
> + else
> +     ret = regmap_write(map, reg,
> +     data->status_buf[i]);

Yes that's what I noticed too. And that's why cpcap was working for
me with ack_invert and without it earlier.

> However, this still doesn't resolve the issue I have with my
> device/driver because it ends up writing 1's to all the other bits in
> the ack register which keeps my device's interrupt from de-asserting.
> Perhaps that's a strange behavior of my device that it allows you to
> 'set' interrupt source bits which causes the interrupt to stay
> asserted? I'm also wondering if my issue is that I currently have the
> interrupt registered as such:
> 
> ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
> IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING, 0, &gsc_irq_chip,
> &irq_data);
> 
> Perhaps this should be IRQF_TRIGGER_LOW as the device will not
> de-assert its IRQ# until all source bits are cleared.

Yes could be. For cpcap, we have IRQ_TYPE_LEVEL_HIGH configured in the
motorola-cpcap-mapphone.dtsi file.

> Tony, I thought that your pcap issue was that it truly did not have an
> inverted ack and the fact that ack_invert did not work was why you
> never noticed any issue. If this is true I would think you would want
> to disable ack_invert but not necessarily enable clear_ack. Did your
> testing show it needed to toggle the ack to clear it?

Well I looked at the v3.0.8 Motorola Linux Android kernel, it actually
does clear_ack. So I'd rather keep the same logic as we have no proper
documentation for cpcap. I also confirmed still works without ack_invert
too while ack_invert now is broken. But using clear_ack now that we
have it working seems safer.

Regards,

Tony