[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sf3wlwlz.ffs@tglx>
Date: Wed, 20 Dec 2023 16:30:48 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: James Tai [戴志峰] <james.tai@...ltek.com>, Marc
Zyngier
<maz@...nel.org>, Rob
Herring <robh+dt@...nel.org>, Krzysztof Kozlowski
<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, kernel test
robot <lkp@...el.com>, Dan Carpenter <error27@...il.com>
Subject: RE: [PATCH v3 2/6] irqchip: Add interrupt controller support for
Realtek DHC SoCs
On Tue, Dec 19 2023 at 03:15, James Tai [戴志峰] wrote:
>>On Wed, Nov 29 2023 at 13:43, James Tai wrote:
>>> +static inline void realtek_intc_clear_ints_bit(struct
>>> +realtek_intc_data *data, int bit) {
>>> + writel(BIT(bit) & ~1, data->base + data->info->isr_offset);
>>
>>That '& ~1' solves what aside of preventing bit 0 from being written?
>>
> The ISR register uses bit 0 to clear or set ISR status.
> Write 0 to clear bits and write 1 to set bits.
> Therefore, to clear the interrupt status, bit 0 should consistently be
> set to '0'.
And how does BIT(bit) with 1 <= bit <= 31 end up having bit 0 set?
Also a comment explaining the reasoning here would be helpful.
Powered by blists - more mailing lists