[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMpxmJV+uO0bUa5cEqXnJT97zD8dqwuL9E5ij4Cu0o_fqWiPfg@mail.gmail.com>
Date: Tue, 12 May 2020 19:12:37 +0200
From: Bartosz Golaszewski <bgolaszewski@...libre.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
Linus Walleij <linus.walleij@...aro.org>,
Jonathan Cameron <jic23@...nel.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
linux-gpio <linux-gpio@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-iio@...r.kernel.org,
Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v4 2/2] irq/irq_sim: simplify the API
wt., 12 maj 2020 o 17:37 Marc Zyngier <maz@...nel.org> napisaĆ(a):
>
> > - */
> > -int irq_sim_irqnum(struct irq_sim *sim, unsigned int offset)
> > -{
> > - return sim->irqs[offset].irqnum;
> > + irq_ctx = irq_data_get_irq_chip_data(irqd);
> > +
> > + if (irq_ctx->enabled) {
> > + set_bit(irqd_to_hwirq(irqd), irq_ctx->work_ctx->pending);
> > + irq_work_queue(&irq_ctx->work_ctx->work);
> > + }
> > }
> > -EXPORT_SYMBOL_GPL(irq_sim_irqnum);
> > +EXPORT_SYMBOL_GPL(irq_sim_fire);
>
> Rather than using an ad-hoc API to queue an interrupt, why don't you
> actually implement the interface that already exists for this at
> the irqchip level (irq_set_irqchip_state, which allows the pending
> state to be set)?
>
Yes, this is great, thanks for bringing this to my attention. I can
drop another function from the API.
Bart
Powered by blists - more mailing lists