Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3667024imj; Tue, 12 Feb 2019 02:38:41 -0800 (PST) X-Google-Smtp-Source: AHgI3IYK0L1ByVYMWOCZHEQKIo8DDVoqh5WO2LEszd0hSSt5CnSBRemYgkr2YEtP99u0Sb95s6Wp X-Received: by 2002:a17:902:24d:: with SMTP id 71mr3230181plc.225.1549967921658; Tue, 12 Feb 2019 02:38:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549967921; cv=none; d=google.com; s=arc-20160816; b=vwYATCVyguM8NP/SIqetCJyB8oxaTOvba+m5en0zv3TE7aDDFz4eXD3qymqaU1MFNy TTtyQDvNw1AUEbecYNUGbPhBqohnXMu4AOVP/3GmrCA7uBxsWjSdCzCg61na5+N1zAzq TpsE870AffsBs66xXDi2OdM+gTwyUlKKmbqfB119FXfYhmam/0zwyL0Mizd7d5PLju7s EXl74dgUYQzFP2+joDxH2XVHiER9V3QsoOIr9859RAQHgJBcPs+/JXGcSA11FBVQQjuH 5PnbXuN9Rf0zDbHVogl5Lq3a3Ezw1GMnc1ii6CFc5gR+bX0z78TJDvhDM8BKGdcu/NpP b1Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=1XrINfiykEItjpkj9w/akl+IWNcNz4ULWAKxX25eP+o=; b=Y4kPKXujc82qrEvqrd38lqzwNscxWs+DHx2YgJuK+An+iZWNtW6pbKHtcI/zFohb9h 75huX3whvHbet9yaYUgOh2zRXFvbz+YusujAJEdp8PF61PVE87bo8lNEMuigak+yeokQ WH5EPUe3GtrmeGtvRZdek6H38Y+dKj7dwoNE1wXMQl8SyF6K8pveP56abSjxvvLd5VSV wh9WEfQ3HE1iyTapVPoIN0W9VL4jdBWFSVngw0YsV3AtJUO7woIUpjv4ByTMYMhAuQyP ePwCAW3a11P9XVyS3gL09fuXeZXnMMqAOFZ+HPkcI4c+Fkdvd5BrhRh/wjCponm7Xgmo 8Vfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=XBMg4IDq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c12si2518223pgd.39.2019.02.12.02.38.26; Tue, 12 Feb 2019 02:38:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=XBMg4IDq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728874AbfBLKh6 (ORCPT + 99 others); Tue, 12 Feb 2019 05:37:58 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:33645 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726756AbfBLKh5 (ORCPT ); Tue, 12 Feb 2019 05:37:57 -0500 Received: by mail-ot1-f67.google.com with SMTP id i20so3648160otl.0 for ; Tue, 12 Feb 2019 02:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1XrINfiykEItjpkj9w/akl+IWNcNz4ULWAKxX25eP+o=; b=XBMg4IDqI9/0xng1Ga7XXJd5PZJSBUlvr21ts27NbxquTpY7Ca0ULjAHMKxl58ahEF /GalBcRXUzdW700de8hcsamlo7m36OtKHGLr9wL+NBSXxsjaVZkaE25HzR1J9eoNuM89 Kd2lk5O0pCE23wVVM86PXqz6QD6/gzyPkMUYynjm42Go4IQcCq9F3jiMKLP55l3A8oLg dMfiI504oHEOZhImbwJ8h/KnxNAhoDNLx9t8o0cTDCDqgOGqz6WFHWhd3e8hFIUwqad/ ORXRSC6xOF12PFXmfTliV4ZUGr2UmfHg2oxvM3SPi4Mr0VZIPy10S/rC7uMR6sjCMWIc SUtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1XrINfiykEItjpkj9w/akl+IWNcNz4ULWAKxX25eP+o=; b=jgQxwX2Z1LwwuAkqsaMS0T/Tq3dOkA4EZMSFRDXLCFLQ8PRbh5GojxhscIW0FpwH9J a2HWb+uJ688WF/J2tlOtHDWk4bgWEleGy0d+Fmn0HW3HehQwMBnecBQl4o8XihOyVYM7 DKMSI5ZQuBCyFuOjIBbPFckIblTaGuc4bp8yOofDFni9U4OZfJ76eLkqyoKGTY04DLRy lkQJ3aLEjlNhl7lMZf0tLwAwcHhtr5IQUhdjI/0UPi5oTJBFhU7Vk2K9Bf5KjHIHjZxZ uHpaQf2rXM55oNh1zSAnM6v8mNT3UTTD4yRi8dQOnoMF9sXaN7tOCA1Dw1FQOBjVJ8A5 rL4Q== X-Gm-Message-State: AHQUAuZOpnlllxE0K661IZATJxkNQeh+bjKW652R57t04VMiP4bzL284 zC41wxKg9OIiiAtR7Y6bsfm6Va3+4ImPINNVXmAKlg== X-Received: by 2002:a9d:32c7:: with SMTP id u65mr2925784otb.236.1549967876645; Tue, 12 Feb 2019 02:37:56 -0800 (PST) MIME-Version: 1.0 References: <20190129084411.30495-1-brgl@bgdev.pl> <20190129084411.30495-4-brgl@bgdev.pl> <656763ec-41b9-cdee-22bd-1f32d74473a0@arm.com> In-Reply-To: From: Bartosz Golaszewski Date: Tue, 12 Feb 2019 11:37:45 +0100 Message-ID: Subject: Re: [PATCH v2 3/9] irq/irq_sim: provide irq_sim_fire_type() To: Marc Zyngier Cc: Bartosz Golaszewski , Linus Walleij , Thomas Gleixner , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , linux-gpio , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org wt., 12 lut 2019 o 11:27 Marc Zyngier napisa=C5=82(a= ): > > On 12/02/2019 09:19, Bartosz Golaszewski wrote: > > wt., 12 lut 2019 o 10:10 Marc Zyngier napisa=C5= =82(a): > >> > >> On 29/01/2019 08:44, Bartosz Golaszewski wrote: > >>> From: Bartosz Golaszewski > >>> > >>> Provide a more specialized variant of irq_sim_fire() that allows to > >>> specify the type of the fired interrupt. The type is stored in the > >>> dummy irq context struct via the set_type callback. > >>> > >>> Signed-off-by: Bartosz Golaszewski > >>> --- > >>> include/linux/irq_sim.h | 9 ++++++++- > >>> kernel/irq/irq_sim.c | 26 ++++++++++++++++++++++---- > >>> 2 files changed, 30 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h > >>> index b96c2f752320..647a6c8ffb31 100644 > >>> --- a/include/linux/irq_sim.h > >>> +++ b/include/linux/irq_sim.h > >>> @@ -23,6 +23,7 @@ struct irq_sim_work_ctx { > >>> > >>> struct irq_sim_irq_ctx { > >>> bool enabled; > >>> + unsigned int type; > >>> }; > >>> > >>> struct irq_sim { > >>> @@ -37,7 +38,13 @@ int irq_sim_init(struct irq_sim *sim, unsigned int= num_irqs); > >>> int devm_irq_sim_init(struct device *dev, struct irq_sim *sim, > >>> unsigned int num_irqs); > >>> void irq_sim_fini(struct irq_sim *sim); > >>> -void irq_sim_fire(struct irq_sim *sim, unsigned int offset); > >>> +void irq_sim_fire_type(struct irq_sim *sim, > >>> + unsigned int offset, unsigned int type); > >>> int irq_sim_irqnum(struct irq_sim *sim, unsigned int offset); > >>> > >>> +static inline void irq_sim_fire(struct irq_sim *sim, unsigned int of= fset) > >>> +{ > >>> + irq_sim_fire_type(sim, offset, IRQ_TYPE_DEFAULT); > >>> +} > >>> + > >>> #endif /* _LINUX_IRQ_SIM_H */ > >>> diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c > >>> index 2bcdbab1bc5a..e3160b5e59b8 100644 > >>> --- a/kernel/irq/irq_sim.c > >>> +++ b/kernel/irq/irq_sim.c > >>> @@ -25,6 +25,15 @@ static void irq_sim_irqunmask(struct irq_data *dat= a) > >>> irq_ctx->enabled =3D true; > >>> } > >>> > >>> +static int irq_sim_set_type(struct irq_data *data, unsigned int type= ) > >>> +{ > >>> + struct irq_sim_irq_ctx *irq_ctx =3D irq_data_get_irq_chip_data(= data); > >>> + > >>> + irq_ctx->type =3D type; > >>> + > >>> + return 0; > >>> +} > >>> + > >>> static void irq_sim_handle_irq(struct irq_work *work) > >>> { > >>> struct irq_sim_work_ctx *work_ctx; > >>> @@ -107,6 +116,7 @@ int irq_sim_init(struct irq_sim *sim, unsigned in= t num_irqs) > >>> sim->chip.name =3D "irq_sim"; > >>> sim->chip.irq_mask =3D irq_sim_irqmask; > >>> sim->chip.irq_unmask =3D irq_sim_irqunmask; > >>> + sim->chip.irq_set_type =3D irq_sim_set_type; > >>> > >>> sim->work_ctx.pending =3D bitmap_zalloc(num_irqs, GFP_KERNEL); > >>> if (!sim->work_ctx.pending) { > >>> @@ -192,21 +202,29 @@ irq_sim_get_ctx(struct irq_sim *sim, unsigned i= nt offset) > >>> } > >>> > >>> /** > >>> - * irq_sim_fire - Enqueue an interrupt. > >>> + * irq_sim_fire_type - Enqueue an interrupt. > >>> * > >>> * @sim: The interrupt simulator object. > >>> * @offset: Offset of the simulated interrupt which should be fi= red. > >>> + * @type: Type of the fired interrupt. Must be one of the followi= ng: > >>> + * IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, > >>> + * IRQ_TYPE_EDGE_BOTH, IRQ_TYPE_LEVEL_HIGH, > >>> + * IRQ_TYPE_LEVEL_LOW, IRQ_TYPE_DEFAULT > >>> */ > >>> -void irq_sim_fire(struct irq_sim *sim, unsigned int offset) > >>> +void irq_sim_fire_type(struct irq_sim *sim, > >>> + unsigned int offset, unsigned int type) > >>> { > >>> struct irq_sim_irq_ctx *ctx =3D irq_sim_get_ctx(sim, offset); > >>> > >>> - if (ctx->enabled) { > >>> + /* Only care about relevant flags. */ > >>> + type &=3D IRQ_TYPE_SENSE_MASK; > >>> + > >>> + if (ctx->enabled && (ctx->type & type)) { > >> > >> I wonder how realistic this is, given that you do not track the releas= e > >> of a level. In short, mo matter what the type is, you treat everything > >> as edge. > >> > >> What is the point of this? > >> > > > > When userspace wants to monitor GPIO line interrupts, the GPIO > > framework requests a threaded interrupt with IRQF_TRIGGER_FALLING, > > IRQF_TRIGGER_RISING or both. The testing module tries to act like real > > hardware and so if we pass only one of the *_TRIGGER_* flags, we want > > the simulated interrupt of corresponding type to be fired. > > Well, that's not how HW works. > > > > > Another solution - if you don't like this one - would be to have more > > specialized functions: irq_sim_fire_rising() and > > irq_sim_fire_falling(). How about that? > > I think you're missing the point. So far, your API has been "an > interrupt has fired", no matter what the trigger is, and that's fine. > That's just modeling the output of an abstract interrupt controller into > whatever the irqsim is simulating. > > Now, what you're exposing is "this is how the line changed". Which is an > entirely different business, as you're now exposing the device output > line. Yes, you can model it with raising/falling, but you need at least > resampling for level interrupts, and actual edge detection (raising > followed by raising only generates a single interrupt, while > raising-falling-raising generates two). > This logic is later taken care of in the gpio-mockup driver in this series. It checks the line state changes and decides if the interrupt should be fired. Bart > At the moment, I don't see any of that so I seriously doubt the validity > of the approach. >