Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <48e32131-2313-5b0e-ac1b-530d0118de18@quicinc.com>
Date:   Thu, 17 Feb 2022 13:34:14 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.1
Subject: Re: [PATCH] regmap-irq: Update interrupt clear register for proper
 reset
Content-Language: en-US
To:     Mark Brown <broonie@kernel.org>
CC:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        <linux-kernel@vger.kernel.org>,
        Charles Keepax <ckeepax@opensource.cirrus.com>,
        "Srinivas Kandagatla [ B [ B [ B" <srinivas.kandagatla@linaro.org>
References: <20220216100026.25543-1-quic_pkumpatl@quicinc.com>
 <Yg0tUlQ/Qs8AHa4O@sirena.org.uk>
From:   Prasad Kumpatla <quic_pkumpatl@quicinc.com>
In-Reply-To: <Yg0tUlQ/Qs8AHa4O@sirena.org.uk>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2/16/2022 10:28 PM, Mark Brown wrote:
Thanks for your time Mark Brown.
> On Wed, Feb 16, 2022 at 03:30:26PM +0530, Prasad Kumpatla wrote:
>> With the existing logic where clear_ack is true, interrupt clear register
>> reset is not handled properly. Due to this only the first interrupts get
>> processed properly and further interrupts are blocked due to interrupt
>> clear register is not reset. So writing 0x00 and 0xff(when ack_invert is
>> true) should have no effect, other than clearing the ACKs just set.
> This commit log still has the problem that it's not clearly describing
> the problem and I've forgotten again - in what way is the interrupt
> clear reset not handled properly?  What should happen and what does
> happen?
Okay, will elaborate the commit message and resend.
>>   				if (d->chip->ack_invert && !ret)
>> -					ret = regmap_write(map, reg,
>> -							   d->mask_buf[i]);
>> +					ret = regmap_write(map, reg, 0xff);
> Why only 0xff and not UINT_MAX?
Okay.
>
>>   				else if (!ret)
>> -					ret = regmap_write(map, reg,
>> -							   ~d->mask_buf[i]);
>> +					ret = regmap_write(map, reg, 0x00);
> Please write 0 normally, no need for 00.
Okay.