[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84a1ed7e4442e04e16730ae112a43aea@kernel.org>
Date: Fri, 08 Apr 2022 13:26:40 +0100
From: Marc Zyngier <maz@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Thierry Reding <thierry.reding@...il.com>,
Joey Gouly <joey.gouly@....com>,
Jonathan Hunter <jonathanh@...dia.com>,
Hector Martin <marcan@...can.st>,
Sven Peter <sven@...npeter.dev>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Andy Gross <agross@...nel.org>,
Jeffrey Hugo <jeffrey.l.hugo@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Basavaraj Natikar <Basavaraj.Natikar@....com>,
Shyam Sundar S K <Shyam-sundar.S-k@....com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
linux-tegra <linux-tegra@...r.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
linux-arm-msm@...r.kernel.org,
Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v2 10/10] Documentation: Update the recommended pattern
for GPIO irqchips
On 2022-04-08 12:33, Andy Shevchenko wrote:
> On Wed, Apr 6, 2022 at 1:57 PM Marc Zyngier <maz@...nel.org> wrote:
>>
>> Update the documentation to get rid of the per-gpio_irq_chip
>> irq_chip structure, and give examples of the new pattern.
>
> ...
>
>> + static void my_gpio_mask_irq(struct irq_data *d)
>> + {
>> + struct gpio_chip *gc = irq_desc_get_handler_data(d);
>> +
>> + /*
>> + * Perform any necessary action to mask the interrupt,
>> + * and then call into the core code to synchronise the
>> + * state.
>> + */
>> +
>> + gpiochip_disable_irq(gc, d->hwirq);
>
> (1)
>
>> + }
>> +
>> + static void my_gpio_unmask_irq(struct irq_data *d)
>> + {
>> + struct gpio_chip *gc = irq_desc_get_handler_data(d);
>
>> + gpiochip_disable_irq(gc, d->hwirq);
>
> (2)
>
>> + /*
>> + * Perform any necessary action to unmask the interrupt,
>> + * after having called into the core code to synchronise
>> + * the state.
>> + */
>> + }
>
> If (1) and (2) being the same is not a mistake (typo) it probably
> needs additional explanation.
Well spotted, this is definitely a copy-paste issue.
I'll fix this locally.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists